summary refs log tree commit diff stats
path: root/results/classifier/108/other/1722857
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/108/other/1722857')
-rw-r--r--results/classifier/108/other/172285727
1 files changed, 27 insertions, 0 deletions
diff --git a/results/classifier/108/other/1722857 b/results/classifier/108/other/1722857
new file mode 100644
index 000000000..1c9590bae
--- /dev/null
+++ b/results/classifier/108/other/1722857
@@ -0,0 +1,27 @@
+vnc: 0.644
+device: 0.613
+semantic: 0.524
+graphic: 0.519
+boot: 0.394
+socket: 0.354
+network: 0.298
+other: 0.259
+files: 0.202
+debug: 0.185
+performance: 0.156
+PID: 0.123
+permissions: 0.076
+KVM: 0.013
+
+Missing PCI "programming interface" ID emulation for USB host controllers
+
+Qemu doesn't currently emulate the correct value of the "register level programming interface" field in the PCI config space of USB host controllers. As a result, some guest operating systems (most notably Windows) fail to load e.g. generic xHCI drivers, and instead ask for a vendor-specific driver, which may not be always available.
+
+Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC) uPD720202 xHCI controller. However, in the PCI config space, it shows us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A Windows guest booted with this option will not recognize devices attached to the XHCI controller unless drivers from Renesas are manually installed first, even though recent Windows versions include a generic xHCI driver that works perfectly well with real uPD720202 hardware.
+
+That sounds surprising ... according to the source code:
+https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=v5.1.0#l3386
+... QEMU already sets 0x30 as programming interface byte there. Could you please double-check whether your problem still occurs with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+