gitlab scraper: download in toml and text format

9 files changed, 132 insertions, 0 deletions

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 000000000..e3f9da29a
--- /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 000000000..e5a68adc4
--- /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 000000000..09eafb6fd
--- /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 000000000..a525f8cd0
--- /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 000000000..0d7025640
--- /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 000000000..a3c0f2bf4
--- /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 000000000..98f20175b
--- /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 000000000..f0edb7546
--- /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 000000000..b8059db50
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_arm/accel_missing/443
@@ -0,0 +1 @@
+QEMU on Windows aarch64