gitlab scraper: download in toml and text format

4 files changed, 89 insertions, 0 deletions

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 000000000..abe8d86b5
--- /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 000000000..35d97eb4c
--- /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 000000000..eca6855ca
--- /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 000000000..2514e8815
--- /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?