gitlab scraper: download in toml and text format

1 files changed, 0 insertions, 29 deletions

diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/2705.toml b/gitlab/issues/target_missing/host_missing/accel_missing/2705.toml
deleted file mode 100644
index 76efed16..00000000
--- a/gitlab/issues/target_missing/host_missing/accel_missing/2705.toml
+++ /dev/null
@@ -1,29 +0,0 @@
-id = 2705
-title = "USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X)"
-state = "closed"
-created_at = "2024-12-01T15:45:07.801Z"
-closed_at = "2025-03-06T05:32:11.312Z"
-labels = ["USB", "hostos: macOS"]
-url = "https://gitlab.com/qemu-project/qemu/-/issues/2705"
-host-os = "Any"
-host-arch = "x86-64, aarch64"
-qemu-version = "9.2.0-rc2"
-guest-os = "macOS"
-guest-arch = "x86-64, aarch64"
-description = "n/a"
-reproduce = """1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above.
-2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off`
-3. Boot macOS.
-
-USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable.
-
-
-While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection:
-
- * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.)
- * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2.
- * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped.
- * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references.
-
-It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup."""
-additional = "n/a"