qemu-system-aarch64: -device usb-host,vendorid=0x12d1,productid=0x0003a: 'usb-host' is not a valid device model name
ln -sf /usr/local/lib/libusb-1.0.so.0.2.0 /lib64/libusb-1.0.so.0
From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed,
re-implemented by libusbx. So you should build qemu with --enable-libusb, then
you can use usb pass-through capacity.
libusb-1.0.23编译安装
yum -y install libudev-devel ./configure make install -j${nproc}
qemu-system-aarch64: undefined symbol: libusb_wrap_sys_device
[root@localhost cloud_images]# ldd /usr/local/bin/qemu-system-aarch64| grep usb libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x0000ffffacda0000)
Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the '-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the 'LD_RUN_PATH' environment variable during linking - use the '-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to '/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages.
[root@localhost build]# ../configure --enable-kvm --disable-xen --enable-libusb --enable-debug-info --enable-debug --enable-sdl --enable-vhost-net --enable-numa --enable-virtfs --target-list=aarch64-softmmu ERROR: User requested feature libusb configure was not able to find it. Install libusb devel >= 1.0.13 [root@localhost build]#
[root@localhost cloud_images]# ls /dev/input/by-path/ -al total 0 drwxrwxrwx. 2 root root 100 Oct 27 03:53 . drwxrwxrwx. 4 root root 180 Oct 27 03:53 .. lrwxrwxrwx. 1 root root 9 Oct 27 03:53 pci-0000:7a:01.0-usb-0:1.1:1.0-event-kbd -> ../event1 lrwxrwxrwx. 1 root root 9 Oct 27 03:53 pci-0000:7a:01.0-usb-0:1.1:1.1-event-mouse -> ../event2 lrwxrwxrwx. 1 root root 9 Oct 27 03:53 pci-0000:7a:01.0-usb-0:1.1:1.1-mouse -> ../mouse0 [root@localhost cloud_images]#
[root@localhost ~]# ls /dev/bus/usb/003/001 -al
[root@localhost ~]# lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M [root@localhost ~]#
For example... If I run lsusb -t and get /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 10: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 11: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M I could decide to pass these by -device usb-host,hostbus=3,hostport=10 -device usb-host,hostbus=3,hostport=11 And those correspond to the physical slots. However the bus and port will differ for a USB 3.0 slot depending on if a USB 2.0 device or USB 3.0 device is plugged into it, but the port for each device will remain consistent. Such variance does not exist for USB 2.0 slots. /* update: USB Hubs */ Use dots to separate the ports. So if you had ... /: Bus 03 |__ Port 2: some stuff |__ Port 1: some stuff
Example Assigning Host USB device to a Guest VM
This example is based on qemu-kvm (0.15.0) as installed in Fedora 15. Will first show how to do this manually, and second how to do it using the virt-manager tool. This HOWTO is limited to UHCI devices (no USB2 EHCI).
Here we'll use a phone attached to the host:
# lsusb ... Bus 002 Device 003: ID 18d1:4e11 Google Inc. Nexus One
(Note the Bus and device numbers).
Manually, using qemu-kvm command line
#/usr/bin/qemu-kvm -m 1024 -name f15 -drive file=/images/f15.img,if=virtio -usb -device usb-host,hostbus=2,hostaddr=3
Here we add the -usb to add a host controller, and add -device usb-host,hostbus=2,hostaddr=3 to add the host's USB device at Bus 2, Device 3. Simple as that.
Now, we can verify this in the guest:
$ lspci ... 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
$ lsusb Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 18d1:4e11 Google Inc. Nexus One Phone
And on the phone enable USB Mass Storage, and the guest should display a dialog seeing a new USB filesystem. Open it and...
$ ls /media/[mountpoint] Android/ data/ DCIM/ ...
USB Quick Start =============== XHCI controller support ----------------------- QEMU has XHCI host adapter support. The XHCI hardware design is much more virtualization-friendly when compared to EHCI and UHCI, thus XHCI emulation uses less resources (especially cpu). So if your guest supports XHCI (which should be the case for any operating system released around 2010 or later) we recommend using it: qemu -device qemu-xhci XHCI supports USB 1.1, USB 2.0 and USB 3.0 devices, so this is the only controller you need. With only a single USB controller (and therefore only a single USB bus) present in the system there is no need to use the bus= parameter when adding USB devices. EHCI controller support ----------------------- The QEMU EHCI Adapter supports USB 2.0 devices. It can be used either standalone or with companion controllers (UHCI, OHCI) for USB 1.1 devices. The companion controller setup is more convenient to use because it provides a single USB bus supporting both USB 2.0 and USB 1.1 devices. See next section for details. When running EHCI in standalone mode you can add UHCI or OHCI controllers for USB 1.1 devices too. Each controller creates its own bus though, so there are two completely separate USB buses: One USB 1.1 bus driven by the UHCI controller and one USB 2.0 bus driven by the EHCI controller. Devices must be attached to the correct controller manually. The easiest way to add a UHCI controller to a 'pc' machine is the '-usb' switch. QEMU will create the UHCI controller as function of the PIIX3 chipset. The USB 1.1 bus will carry the name "usb-bus.0". You can use the standard -device switch to add a EHCI controller to your virtual machine. It is strongly recommended to specify an ID for the controller so the USB 2.0 bus gets an individual name, for example '-device usb-ehci,id=ehci". This will give you a USB 2.0 bus named "ehci.0". When adding USB devices using the -device switch you can specify the bus they should be attached to. Here is a complete example: qemu -M pc ${otheroptions} -drive if=none,id=usbstick,file=/path/to/image -usb -device usb-ehci,id=ehci -device usb-tablet,bus=usb-bus.0 -device usb-storage,bus=ehci.0,drive=usbstick This attaches a USB tablet to the UHCI adapter and a USB mass storage device to the EHCI adapter. Companion controller support ---------------------------- The UHCI and OHCI controllers can attach to a USB bus created by EHCI as companion controllers. This is done by specifying the masterbus and firstport properties. masterbus specifies the bus name the controller should attach to. firstport specifies the first port the controller should attach to, which is needed as usually one EHCI controller with six ports has three UHCI companion controllers with two ports each. There is a config file in docs which will do all this for you, just try ... qemu -readconfig docs/config/ich9-ehci-uhci.cfg ... then use "bus=ehci.0" to assign your USB devices to that bus. Using the '-usb' switch for 'q35' machines will create a similar USB controller configuration. More USB tips & tricks ====================== Recently the USB pass through driver (also known as usb-host) and the QEMU USB subsystem gained a few capabilities which are available only via qdev properties, i,e. when using '-device'. physical port addressing ------------------------ First you can (for all USB devices) specify the physical port where the device will show up in the guest. This can be done using the "port" property. UHCI has two root ports (1,2). EHCI has six root ports (1-6), the emulated (1.1) USB hub has eight ports. Plugging a tablet into UHCI port 1 works like this: -device usb-tablet,bus=usb-bus.0,port=1 Plugging a hub into UHCI port 2 works like this: -device usb-hub,bus=usb-bus.0,port=2 Plugging a virtual USB stick into port 4 of the hub just plugged works this way: -device usb-storage,bus=usb-bus.0,port=2.4,drive=... You can do basically the same in the monitor using the device_add command. If you want to unplug devices too you should specify some unique id which you can use to refer to the device ... (qemu) device_add usb-tablet,bus=usb-bus.0,port=1,id=my-tablet (qemu) device_del my-tablet ... when unplugging it with device_del. USB pass through hints ---------------------- The usb-host driver has a bunch of properties to specify the device which should be passed to the guest: hostbus=<nr> -- Specifies the bus number the device must be attached to. hostaddr=<nr> -- Specifies the device address the device got assigned by the guest os. hostport=<str> -- Specifies the physical port the device is attached to. vendorid=<hexnr> -- Specifies the vendor ID of the device. productid=<hexnr> -- Specifies the product ID of the device. In theory you can combine all these properties as you like. In practice only a few combinations are useful: (1) vendorid+productid -- match for a specific device, pass it to the guest when it shows up somewhere in the host. (2) hostbus+hostport -- match for a specific physical port in the host, any device which is plugged in there gets passed to the guest. (3) hostbus+hostaddr -- most useful for ad-hoc pass through as the hostaddr isn't stable, the next time you plug in the device it gets a new one ... Note that USB 1.1 devices are handled by UHCI/OHCI and USB 2.0 by EHCI. That means a device plugged into the very same physical port may show up on different buses depending on the speed. The port I'm using for testing is bus 1 + port 1 for 2.0 devices and bus 3 + port 1 for 1.1 devices. Passing through any device plugged into that port and also assign them to the correct bus can be done this way: qemu -M pc ${otheroptions} -usb -device usb-ehci,id=ehci -device usb-host,bus=usb-bus.0,hostbus=3,hostport=1 -device usb-host,bus=ehci.0,hostbus=1,hostport=1 enjoy, Gerd -- Gerd Hoffmann <kraxel@redhat.com>
They mention -device usb-host,hostbus=bus,hostaddr=addr Pass through the host device identified by bus and addr -device usb-host,vendorid=vendor,productid=product Pass through the host device identified by vendor and product ID But they don't mention that you can do -device usb-host,hostbus=bus,hostport=port For example... If I run lsusb -t and get /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 10: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 11: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M I could decide to pass these by -device usb-host,hostbus=3,hostport=10 -device usb-host,hostbus=3,hostport=11 And those correspond to the physical slots. However the bus and port will differ for a USB 3.0 slot depending on if a USB 2.0 device or USB 3.0 device is plugged into it, but the port for each device will remain consistent. Such variance does not exist for USB 2.0 slots.
