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?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1722857
Title:
Missing PCI "programming interface" ID emulation for USB host
controllers
Status in QEMU:
Incomplete
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1722857/+subscriptions
