add gitlab issues in toml format

25 files changed, 1349 insertions, 0 deletions

diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/1003.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1003.toml
new file mode 100644
index 00000000..5a85bdab
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1003.toml
@@ -0,0 +1,29 @@
+id = 1003
+title = "\"Cannot allocate memory\" when boots a VM > 1026GB memory with -accel kvm"
+state = "closed"
+created_at = "2022-04-24T02:39:33.819Z"
+closed_at = "2022-06-19T05:12:22.616Z"
+labels = ["accel: KVM", "workflow::Triaged"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1003"
+host-os = "Debian 11.2"
+host-arch = "x86"
+qemu-version = "6.2.0"
+guest-os = "not relavant to this problem"
+guest-arch = "x86"
+description = """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."""
+reproduce = """1. sysctl vm.overcommit_memory=1  # enable overcommit first
+2. qemu-system-x86_64 -m 1027G -accel kvm -vnc :1"""
+additional = """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/target_missing/host_missing/accel_KVM/1009.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1009.toml
new file mode 100644
index 00000000..9286b3a6
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1009.toml
@@ -0,0 +1,33 @@
+id = 1009
+title = "Nested KVM Networking Issue (OpenStack)"
+state = "opened"
+created_at = "2022-04-30T12:04:42.261Z"
+closed_at = "n/a"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1009"
+host-os = "(ubuntu 20.04 server)"
+host-arch = "(64 bit cpu architecture)"
+qemu-version = "(latest using sudo apt install virt-manager)"
+guest-os = "(ubuntu 20.04 server)"
+guest-arch = "(64 bit cpu architecture)"
+description = """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 ?"""
+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"""
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/110.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/110.toml
new file mode 100644
index 00000000..e7287092
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/110.toml
@@ -0,0 +1,15 @@
+id = 110
+title = "KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on"
+state = "opened"
+created_at = "2021-05-03T16:47:50.463Z"
+closed_at = "n/a"
+labels = ["Launchpad", "USB", "accel: KVM", "kind::Bug", "workflow::Triaged"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/110"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/1274.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1274.toml
new file mode 100644
index 00000000..88d092f7
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1274.toml
@@ -0,0 +1,42 @@
+id = 1274
+title = "Cannot debug init using \"qemu -s -S\" if init is compiled dynamically or if kvm is enabled"
+state = "closed"
+created_at = "2022-10-25T06:37:16.506Z"
+closed_at = "2023-12-01T19:56:42.721Z"
+labels = ["Documentation", "GDB", "accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1274"
+host-os = "Debian sid (as of 2022-10-22)"
+host-arch = "x86_64"
+qemu-version = "QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b1)"
+guest-os = "Debian sid (as of 2022-10-22)"
+guest-arch = "x86_64"
+description = """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"""
+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."""
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/1344.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1344.toml
new file mode 100644
index 00000000..c89f5095
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1344.toml
@@ -0,0 +1,15 @@
+id = 1344
+title = "custom kernel give me KVM internal error. Suberror: 4"
+state = "closed"
+created_at = "2022-11-28T21:25:26.573Z"
+closed_at = "2022-12-01T03:25:35.275Z"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1344"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/165.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/165.toml
new file mode 100644
index 00000000..81ebedb3
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/165.toml
@@ -0,0 +1,15 @@
+id = 165
+title = "No evdev mouse passthrough with virtio-vga or kvm"
+state = "opened"
+created_at = "2021-05-05T11:17:51.528Z"
+closed_at = "n/a"
+labels = ["Launchpad", "accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/165"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/1936.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1936.toml
new file mode 100644
index 00000000..c0b554a4
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1936.toml
@@ -0,0 +1,15 @@
+id = 1936
+title = "Pass file descriptor to /dev/kvm device node?"
+state = "closed"
+created_at = "2023-10-13T08:39:33.635Z"
+closed_at = "2023-11-06T18:56:26.157Z"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1936"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/1999.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/1999.toml
new file mode 100644
index 00000000..6dd78bdc
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/1999.toml
@@ -0,0 +1,59 @@
+id = 1999
+title = "qemu got sigabrt when using vpp in guest and dpdk for qemu"
+state = "opened"
+created_at = "2023-11-23T06:04:09.084Z"
+closed_at = "n/a"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1999"
+host-os = "Rockylinux 8"
+host-arch = "x86"
+qemu-version = "qemu-kvm-7.2.0-14.el9 (in a container)"
+guest-os = "Ubuntu 22.04.3 LTS"
+guest-arch = "x86"
+description = """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,
+\t\t\t       struct kvm_irq_routing_table *rt,
+\t\t\t       struct kvm_kernel_irq_routing_entry *e,
+\t\t\t       const struct kvm_irq_routing_entry *ue)
+{
+\tstruct kvm_kernel_irq_routing_entry *ei;
+\tint r;
+\tu32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES);
+
+\t/*
+\t * Do not allow GSI to be mapped to the same irqchip more than once.
+\t * Allow only one to one mapping between GSI and non-irqchip routing.
+\t */
+\thlist_for_each_entry(ei, &rt->map[gsi], link)
+\t\tif (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
+\t\t    ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
+\t\t    ue->u.irqchip.irqchip == ei->irqchip.irqchip)
+\t\t\treturn -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
+```"""
+reproduce = """This is a kube-ovn + dpdk env, not easy to reproduce now.."""
+additional = """* 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/target_missing/host_missing/accel_KVM/2321.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2321.toml
new file mode 100644
index 00000000..464d51a4
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2321.toml
@@ -0,0 +1,48 @@
+id = 2321
+title = "Segfault when hibernating a KVM VM with QEMU 8.2.3"
+state = "closed"
+created_at = "2024-05-01T14:42:55.933Z"
+closed_at = "2024-08-26T16:10:33.713Z"
+labels = ["Regression", "accel: KVM", "device:virtio", "workflow::Patch available"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2321"
+host-os = "NixOS unstable"
+host-arch = "x86_64"
+qemu-version = "8.2.3"
+guest-os = "NixOS unstable"
+guest-arch = "x86_64"
+description = """Attempting to hibernate the machine crashes QEMU."""
+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 = """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/target_missing/host_missing/accel_KVM/2324.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2324.toml
new file mode 100644
index 00000000..47b0c1b2
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2324.toml
@@ -0,0 +1,55 @@
+id = 2324
+title = "SELinux is preventing some qemu-kvm operations on CentOS Stream 9"
+state = "opened"
+created_at = "2024-05-03T16:50:08.899Z"
+closed_at = "n/a"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2324"
+host-os = "CentOS Stream release 9"
+host-arch = "x86_64"
+qemu-version = "qemu-img version 8.2.0 (qemu-kvm-8.2.0-11.el9)"
+guest-os = "CentOS Stream release 9"
+guest-arch = "x86_64"
+description = """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
+
+
+```"""
+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 = """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/target_missing/host_missing/accel_KVM/2414.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2414.toml
new file mode 100644
index 00000000..fa105fa7
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2414.toml
@@ -0,0 +1,127 @@
+id = 2414
+title = "qemu 9.0.0 crashing with OpenBSD 7.5"
+state = "closed"
+created_at = "2024-06-29T06:23:16.856Z"
+closed_at = "2024-11-10T07:54:16.281Z"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2414"
+host-os = "Manjaro"
+host-arch = "x86_64"
+qemu-version = "`"
+guest-os = "OpenBSD"
+guest-arch = "x86"
+description = """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."""
+reproduce = "n/a"
+additional = """```
+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/target_missing/host_missing/accel_KVM/2436.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2436.toml
new file mode 100644
index 00000000..b4d580bf
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2436.toml
@@ -0,0 +1,15 @@
+id = 2436
+title = "virtio kvm iofd sigfault bypass"
+state = "opened"
+created_at = "2024-07-14T20:02:06.351Z"
+closed_at = "n/a"
+labels = ["Storage", "accel: KVM", "device:virtio"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2436"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/2445.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2445.toml
new file mode 100644
index 00000000..36930132
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2445.toml
@@ -0,0 +1,95 @@
+id = 2445
+title = "virtio-pci: the number of irq routes keeps increasing and qemu abort"
+state = "opened"
+created_at = "2024-07-18T08:26:41.458Z"
+closed_at = "n/a"
+labels = ["accel: KVM", "device:virtio"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2445"
+host-os = "CentOS Linux release 8.5.2111"
+host-arch = "x86"
+qemu-version = "QEMU emulator version 8.2.0"
+guest-os = "CentOS Linux release 8.5.2111"
+guest-arch = "x86"
+description = """"""
+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 = """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/target_missing/host_missing/accel_KVM/2450.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2450.toml
new file mode 100644
index 00000000..c3e11664
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2450.toml
@@ -0,0 +1,25 @@
+id = 2450
+title = "Intel GVT-g does not produce any output."
+state = "opened"
+created_at = "2024-07-20T08:12:54.555Z"
+closed_at = "n/a"
+labels = ["VFIO", "accel: KVM", "workflow::Needs Info"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2450"
+host-os = "Arch Linux"
+host-arch = "x86_64"
+qemu-version = "9.0.2"
+guest-os = "Windows Server 2022"
+guest-arch = "x86_64"
+description = """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}"""
+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 = """CPU: i7-10700"""
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/2699.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2699.toml
new file mode 100644
index 00000000..84992e24
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2699.toml
@@ -0,0 +1,26 @@
+id = 2699
+title = "kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9)"
+state = "closed"
+created_at = "2024-11-25T08:58:12.606Z"
+closed_at = "2024-12-06T05:27:39.768Z"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2699"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "# /usr/local/bin/qemu-system-x86_64 --version"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """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"""
+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 = """"""
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/2710.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2710.toml
new file mode 100644
index 00000000..775464e1
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2710.toml
@@ -0,0 +1,136 @@
+id = 2710
+title = "QEMU can't detect guest debug support on older (pre v5.7) x86 host kernels due to missing KVM_CAP_SET_GUEST_DEBUG"
+state = "opened"
+created_at = "2024-12-06T02:29:37.267Z"
+closed_at = "n/a"
+labels = ["GDB", "accel: KVM", "kind::Feature Request"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2710"
+host-os = "Ubuntu"
+host-arch = "x86_64"
+qemu-version = "8.2+"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """```
+qemu-system-x86_64: -s: gdbstub: current accelerator doesn't support guest debugging
+```"""
+reproduce = "n/a"
+additional = """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)
+{
+\tint r;
+
+\tswitch (ext) {
+\tcase KVM_CAP_IRQCHIP:
+\tcase KVM_CAP_HLT:
+\tcase KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
+\tcase KVM_CAP_SET_TSS_ADDR:
+\tcase KVM_CAP_EXT_CPUID:
+\tcase KVM_CAP_EXT_EMUL_CPUID:
+\tcase KVM_CAP_CLOCKSOURCE:
+\tcase KVM_CAP_PIT:
+\tcase KVM_CAP_NOP_IO_DELAY:
+\tcase KVM_CAP_MP_STATE:
+\tcase KVM_CAP_SYNC_MMU:
+\tcase KVM_CAP_USER_NMI:
+\tcase KVM_CAP_REINJECT_CONTROL:
+\tcase KVM_CAP_IRQ_INJECT_STATUS:
+\tcase KVM_CAP_IOEVENTFD:
+\tcase KVM_CAP_IOEVENTFD_NO_LENGTH:
+\tcase KVM_CAP_PIT2:
+\tcase KVM_CAP_PIT_STATE2:
+\tcase KVM_CAP_SET_IDENTITY_MAP_ADDR:
+\tcase KVM_CAP_XEN_HVM:
+\tcase KVM_CAP_VCPU_EVENTS:
+\tcase KVM_CAP_HYPERV:
+\tcase KVM_CAP_HYPERV_VAPIC:
+\tcase KVM_CAP_HYPERV_SPIN:
+\tcase KVM_CAP_HYPERV_SYNIC:
+\tcase KVM_CAP_HYPERV_SYNIC2:
+\tcase KVM_CAP_HYPERV_VP_INDEX:
+\tcase KVM_CAP_PCI_SEGMENT:
+\tcase KVM_CAP_DEBUGREGS:
+\tcase KVM_CAP_X86_ROBUST_SINGLESTEP:
+\tcase KVM_CAP_XSAVE:
+\tcase KVM_CAP_ASYNC_PF:
+\tcase KVM_CAP_GET_TSC_KHZ:
+\tcase KVM_CAP_KVMCLOCK_CTRL:
+\tcase KVM_CAP_READONLY_MEM:
+\tcase KVM_CAP_HYPERV_TIME:
+\tcase KVM_CAP_IOAPIC_POLARITY_IGNORED:
+\tcase KVM_CAP_TSC_DEADLINE_TIMER:
+\tcase KVM_CAP_ENABLE_CAP_VM:
+\tcase KVM_CAP_DISABLE_QUIRKS:
+\tcase KVM_CAP_SET_BOOT_CPU_ID:
+ \tcase KVM_CAP_SPLIT_IRQCHIP:
+\tcase KVM_CAP_IMMEDIATE_EXIT:
+\t\tr = 1;
+\t\tbreak;
+\tcase KVM_CAP_ADJUST_CLOCK:
+\t\tr = KVM_CLOCK_TSC_STABLE;
+\t\tbreak;
+\tcase KVM_CAP_X86_GUEST_MWAIT:
+\t\tr = kvm_mwait_in_guest();
+\t\tbreak;
+\tcase KVM_CAP_X86_SMM:
+\t\t/* SMBASE is usually relocated above 1M on modern chipsets,
+\t\t * and SMM handlers might indeed rely on 4G segment limits,
+\t\t * so do not report SMM to be available if real mode is
+\t\t * emulated via vm86 mode.  Still, do not go to great lengths
+\t\t * to avoid userspace's usage of the feature, because it is a
+\t\t * fringe case that is not enabled except via specific settings
+\t\t * of the module parameters.
+\t\t */
+\t\tr = kvm_x86_ops->cpu_has_high_real_mode_segbase();
+\t\tbreak;
+\tcase KVM_CAP_VAPIC:
+\t\tr = !kvm_x86_ops->cpu_has_accelerated_tpr();
+\t\tbreak;
+\tcase KVM_CAP_NR_VCPUS:
+\t\tr = KVM_SOFT_MAX_VCPUS;
+\t\tbreak;
+\tcase KVM_CAP_MAX_VCPUS:
+\t\tr = KVM_MAX_VCPUS;
+\t\tbreak;
+\tcase KVM_CAP_NR_MEMSLOTS:
+\t\tr = KVM_USER_MEM_SLOTS;
+\t\tbreak;
+\tcase KVM_CAP_PV_MMU:\t/* obsolete */
+\t\tr = 0;
+\t\tbreak;
+\tcase KVM_CAP_MCE:
+\t\tr = KVM_MAX_MCE_BANKS;
+\t\tbreak;
+\tcase KVM_CAP_XCRS:
+\t\tr = boot_cpu_has(X86_FEATURE_XSAVE);
+\t\tbreak;
+\tcase KVM_CAP_TSC_CONTROL:
+\t\tr = kvm_has_tsc_control;
+\t\tbreak;
+\tcase KVM_CAP_X2APIC_API:
+\t\tr = KVM_X2APIC_API_VALID_FLAGS;
+\t\tbreak;
+\tdefault:
+\t\tr = 0;
+\t\tbreak;
+\t}
+\treturn 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/target_missing/host_missing/accel_KVM/2712.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/2712.toml
new file mode 100644
index 00000000..2817f7be
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/2712.toml
@@ -0,0 +1,19 @@
+id = 2712
+title = "Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12"
+state = "closed"
+created_at = "2024-12-07T20:54:57.655Z"
+closed_at = "2024-12-14T08:36:17.730Z"
+labels = ["accel: KVM", "guest: Windows"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2712"
+host-os = "Manjaro Linux"
+host-arch = "x86"
+qemu-version = "9.1.2"
+guest-os = "Windows 10, Windows 11 24H2"
+guest-arch = "x86"
+description = """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."""
+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 = """Nothing is displayed in console."""
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/337.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/337.toml
new file mode 100644
index 00000000..1e3c2bdc
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/337.toml
@@ -0,0 +1,15 @@
+id = 337
+title = "QEMU emulator version 6.0.50 Failure with nested FreeBSD bhyve"
+state = "opened"
+created_at = "2021-05-18T01:36:14.390Z"
+closed_at = "n/a"
+labels = ["accel: KVM", "guest: BSD", "hostos: Linux", "kind::Bug", "workflow::Triaged"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/337"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/439.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/439.toml
new file mode 100644
index 00000000..9a1b6d08
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/439.toml
@@ -0,0 +1,15 @@
+id = 439
+title = "Hard crash - qemu-6.0.0 with windows 10 guest"
+state = "opened"
+created_at = "2021-06-19T18:10:19.218Z"
+closed_at = "n/a"
+labels = ["accel: KVM", "device:virtio"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/439"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/477.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/477.toml
new file mode 100644
index 00000000..ef309c1c
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/477.toml
@@ -0,0 +1,20 @@
+id = 477
+title = "Nested kvm-svm does not work since f5cc5a5c16"
+state = "closed"
+created_at = "2021-07-13T05:00:08.959Z"
+closed_at = "2021-07-24T13:25:38.002Z"
+labels = ["Regression", "accel: KVM", "kind::Bug", "workflow::In Progress"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/477"
+host-os = "Debian 10"
+host-arch = "x86_64"
+qemu-version = "6.0.50"
+guest-os = "Debian Linux"
+guest-arch = "x86_64"
+description = """Nested SVM virtualization seems to not work. I bisected this to f5cc5a5c16."""
+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 = """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/target_missing/host_missing/accel_KVM/478.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/478.toml
new file mode 100644
index 00000000..a8158d36
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/478.toml
@@ -0,0 +1,409 @@
+id = 478
+title = "Loss of network trafic when virtual iommu is enabled"
+state = "closed"
+created_at = "2021-07-13T17:56:15.406Z"
+closed_at = "2024-06-25T08:53:02.129Z"
+labels = ["accel: KVM"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/478"
+host-os = "Debian 10.10"
+host-arch = "x86_64"
+qemu-version = "n/a"
+guest-os = "Debian 10.10"
+guest-arch = "x86_64"
+description = "n/a"
+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 = """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/target_missing/host_missing/accel_KVM/504.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/504.toml
new file mode 100644
index 00000000..5e485812
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/504.toml
@@ -0,0 +1,26 @@
+id = 504
+title = "kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed"
+state = "closed"
+created_at = "2021-07-26T10:11:12.471Z"
+closed_at = "2021-07-27T12:29:31.938Z"
+labels = ["accel: KVM", "kind::Bug"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/504"
+host-os = "Gentoo Linux"
+host-arch = "x86 (32bit userland, 64bit kernel)"
+qemu-version = "QEMU emulator version 6.0.90"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """```
+ $ ./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
+```"""
+reproduce = """1. qemu crashes right at start"""
+additional = """- last successfully used qemu version: 5.2.0
+ - first seen failing qemu version: 6.0"""
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/706.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/706.toml
new file mode 100644
index 00000000..61f43ff4
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/706.toml
@@ -0,0 +1,50 @@
+id = 706
+title = "NVMe End-to-End Data Protection"
+state = "opened"
+created_at = "2021-11-03T17:18:35.951Z"
+closed_at = "n/a"
+labels = ["accel: KVM", "block:NVMe", "workflow::Confirmed"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/706"
+host-os = "(openSUSE Tumbleweed 20210929)"
+host-arch = "(x86_64)"
+qemu-version = "(6.1.0)"
+guest-os = "(Initramfs with busybox)"
+guest-arch = "(x86_64)"
+description = """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
+```"""
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/73.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/73.toml
new file mode 100644
index 00000000..69431b92
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/73.toml
@@ -0,0 +1,15 @@
+id = 73
+title = "KVM Windows 98 sound card passthrough is not working for DOS programs.."
+state = "opened"
+created_at = "2021-05-01T08:38:15.949Z"
+closed_at = "n/a"
+labels = ["Audio", "Launchpad", "accel: KVM", "hostos: Windows", "kind::Bug", "workflow::Triaged"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/73"
+host-os = "n/a"
+host-arch = "n/a"
+qemu-version = "n/a"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = "n/a"
+reproduce = "n/a"
+additional = "n/a"
diff --git a/gitlab/issues/target_missing/host_missing/accel_KVM/849.toml b/gitlab/issues/target_missing/host_missing/accel_KVM/849.toml
new file mode 100644
index 00000000..8f7d7c33
--- /dev/null
+++ b/gitlab/issues/target_missing/host_missing/accel_KVM/849.toml
@@ -0,0 +1,30 @@
+id = 849
+title = "High mouse polling rate stutters some applications"
+state = "opened"
+created_at = "2022-01-31T05:52:28.024Z"
+closed_at = "n/a"
+labels = ["VFIO", "accel: KVM", "device:input"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/849"
+host-os = "Proxmox 7.1-10"
+host-arch = "amd64"
+qemu-version = "6.1.0"
+guest-os = "Windows 11"
+guest-arch = "amd64"
+description = """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."""
+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 = """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."""