other: 0.983 permissions: 0.979 device: 0.978 semantic: 0.974 debug: 0.972 files: 0.971 graphic: 0.971 vnc: 0.970 performance: 0.968 PID: 0.964 socket: 0.961 boot: 0.958 KVM: 0.952 network: 0.936 Xbox One controller USB passthrough disconnections and stops I can't properly passthrough my Xbox One controller to a virtual machine; it causes USB disconnections on the host, ultimately preventing it to work (at all) on the guest I've seen a few other cases reported in other websites, which show the same symptoms: - https://www.reddit.com/r/VFIO/comments/97dhbw/qemu_w10_xbox_one_controller - https://unix.stackexchange.com/questions/452751/how-can-i-pass-through-an-xbox-one-controller-to-a-windows-vm-on-ubuntu This is sample: libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/003/016: No such file or directory I think this is a quite long-standing issue, as I've been experiencing through several versions, including the current one (3.1). I can reproduce this 100% of the times, on multiple host O/S distributions (the current one being based on Ubuntu 18.04 x86-64). I compile QEMU directly from source, and execute it via commandline; the command is very long, however, the relevant part is standard (I think): -usb \ -device usb-tablet \ -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ The guest is Windows 10 64bit. Do you get a different behavior if you use "-device usb-ehci" or "-device nec-usb-xhci" instead of the "-usb" parameter? So! These are the options and respective logs; they still don't make the controller work - it doesn't work at all. # option 1 -device nec-usb-xhci \ -device usb-tablet \ -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ # log libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/019: No such file or directory libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/020: No such file or directory libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-10/bConfigurationValue failed ret=-1 errno=2 libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/021: No such file or directory libusb: error [udev_hotplug_event] ignoring udev action bind # option 2 -device usb-ehci \ -device usb-tablet \ -device usb-host,vendorid=0x$VGAPT_XBOX_PAD_VEND_ID,productid=0x$VGAPT_XBOX_PAD_PROD_ID \ # log qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Controller" (full speed) to bus "usb-bus.0", port "2" (high speed) libusb: error [udev_hotplug_event] ignoring udev action bind I've tried another game controller with the second option: # option 2b -device usb-ehci \ -device usb-tablet \ -device usb-host,vendorid=0x$VGAPT_ARCADE_STICK_VEND_ID,productid=0x$VGAPT_ARCADE_STICK_PROD_ID \ # log libusb: error [udev_hotplug_event] ignoring udev action bind qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Arcade Fight Stick" (full speed) to bus "usb-bus.0", port "3" (high speed) and in this configuration, it doesn't work (it does with `-usb`). This happened to me as well, but I managed to find a solution, if I ban the xpad driver through modprobe.d, then the problem disappear. I added the following line: blacklist xpad To this file: /etc/modprobe.d/vfio.conf, rebooted, and then I could use my Xbox One S controller with Qemu, I am not sure if it's a xpad bug or a hardware bug. > This happened to me as well, but I managed to find a solution, if I ban the xpad driver through modprobe.d, then the problem disappear. Thanks, that's very interesting (and useful, although nowadays I use the BT connection). Still an issue as of QEMU 6.0.0rc2. I can't (still) exclude that it's an issue on the host side, although, when it comes to USB passthrough, I don't have issues with similar devices (mice, keyboards etc.). The module blacklist workaround works. This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here: https://gitlab.com/qemu-project/qemu/-/issues/157