1 files changed, 47 insertions, 0 deletions
diff --git a/results/classifier/118/peripherals/2705 b/results/classifier/118/peripherals/2705
new file mode 100644
index 000000000..1c9756cb8
--- /dev/null
+++ b/results/classifier/118/peripherals/2705
@@ -0,0 +1,47 @@
+peripherals: 0.981
+architecture: 0.952
+boot: 0.931
+device: 0.926
+performance: 0.915
+virtual: 0.910
+vnc: 0.865
+semantic: 0.851
+x86: 0.845
+graphic: 0.845
+ppc: 0.818
+debug: 0.771
+arm: 0.743
+mistranslation: 0.726
+user-level: 0.721
+socket: 0.687
+hypervisor: 0.667
+permissions: 0.665
+VMM: 0.631
+risc-v: 0.625
+register: 0.615
+files: 0.565
+PID: 0.548
+KVM: 0.519
+TCG: 0.499
+assembly: 0.499
+i386: 0.473
+kernel: 0.422
+network: 0.411
+
+USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X)
+Steps to reproduce:
+1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above.
+2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off`
+3. Boot macOS.
+
+USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable.
+
+
+While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection:
+
+ * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.)
+ * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2.
+ * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped.
+ * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references.
+
+It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup.