docs/usb2.txt

   1
   2 USB Quick Start
   3 ===============
   4
   5 XHCI controller support
   6 -----------------------
   7
   8 QEMU has XHCI host adapter support.  The XHCI hardware design is much
   9 more virtualization-friendly when compared to EHCI and UHCI, thus XHCI
  10 emulation uses less resources (especially cpu).  So if your guest
  11 supports XHCI (which should be the case for any operating system
  12 released around 2010 or later) we recommend using it:
  13
  14     qemu -device qemu-xhci
  15
  16 XHCI supports USB 1.1, USB 2.0 and USB 3.0 devices, so this is the
  17 only controller you need.  With only a single USB controller (and
  18 therefore only a single USB bus) present in the system there is no
  19 need to use the bus= parameter when adding USB devices.
  20
  21
  22 EHCI controller support
  23 -----------------------
  24
  25 The QEMU EHCI Adapter supports USB 2.0 devices.  It can be used either
  26 standalone or with companion controllers (UHCI, OHCI) for USB 1.1
  27 devices.  The companion controller setup is more convenient to use
  28 because it provides a single USB bus supporting both USB 2.0 and USB
  29 1.1 devices.  See next section for details.
  30
  31 When running EHCI in standalone mode you can add UHCI or OHCI
  32 controllers for USB 1.1 devices too.  Each controller creates its own
  33 bus though, so there are two completely separate USB buses: One USB
  34 1.1 bus driven by the UHCI controller and one USB 2.0 bus driven by
  35 the EHCI controller.  Devices must be attached to the correct
  36 controller manually.
  37
  38 The easiest way to add a UHCI controller to a 'pc' machine is the
  39 '-usb' switch.  QEMU will create the UHCI controller as function of
  40 the PIIX3 chipset.  The USB 1.1 bus will carry the name "usb-bus.0".
  41
  42 You can use the standard -device switch to add a EHCI controller to
  43 your virtual machine.  It is strongly recommended to specify an ID for
  44 the controller so the USB 2.0 bus gets an individual name, for example
  45 '-device usb-ehci,id=ehci".  This will give you a USB 2.0 bus named
  46 "ehci.0".
  47
  48 When adding USB devices using the -device switch you can specify the
  49 bus they should be attached to.  Here is a complete example:
  50
  51     qemu -M pc ${otheroptions}                           \
  52         -drive if=none,id=usbstick,file=/path/to/image   \
  53         -usb                                             \
  54         -device usb-ehci,id=ehci                         \
  55         -device usb-tablet,bus=usb-bus.0                 \
  56         -device usb-storage,bus=ehci.0,drive=usbstick
  57
  58 This attaches a USB tablet to the UHCI adapter and a USB mass storage
  59 device to the EHCI adapter.
  60
  61
  62 Companion controller support
  63 ----------------------------
  64
  65 The UHCI and OHCI controllers can attach to a USB bus created by EHCI
  66 as companion controllers.  This is done by specifying the masterbus
  67 and firstport properties.  masterbus specifies the bus name the
  68 controller should attach to.  firstport specifies the first port the
  69 controller should attach to, which is needed as usually one EHCI
  70 controller with six ports has three UHCI companion controllers with
  71 two ports each.
  72
  73 There is a config file in docs which will do all this for
  74 you, just try ...
  75
  76     qemu -readconfig docs/config/ich9-ehci-uhci.cfg
  77
  78 ... then use "bus=ehci.0" to assign your USB devices to that bus.
  79
  80 Using the '-usb' switch for 'q35' machines will create a similar
  81 USB controller configuration.
  82
  83
  84 More USB tips & tricks
  85 ======================
  86
  87 Recently the USB pass through driver (also known as usb-host) and the
  88 QEMU USB subsystem gained a few capabilities which are available only
  89 via qdev properties, i,e. when using '-device'.
  90
  91
  92 physical port addressing
  93 ------------------------
  94
  95 First you can (for all USB devices) specify the physical port where
  96 the device will show up in the guest.  This can be done using the
  97 "port" property.  UHCI has two root ports (1,2).  EHCI has six root
  98 ports (1-6), the emulated (1.1) USB hub has eight ports.
  99
 100 Plugging a tablet into UHCI port 1 works like this:
 101
 102         -device usb-tablet,bus=usb-bus.0,port=1
 103
 104 Plugging a hub into UHCI port 2 works like this:
 105
 106         -device usb-hub,bus=usb-bus.0,port=2
 107
 108 Plugging a virtual USB stick into port 4 of the hub just plugged works
 109 this way:
 110
 111         -device usb-storage,bus=usb-bus.0,port=2.4,drive=...
 112
 113 You can do basically the same in the monitor using the device_add
 114 command.  If you want to unplug devices too you should specify some
 115 unique id which you can use to refer to the device ...
 116
 117         (qemu) device_add usb-tablet,bus=usb-bus.0,port=1,id=my-tablet
 118         (qemu) device_del my-tablet
 119
 120 ... when unplugging it with device_del.
 121
 122
 123 USB pass through hints
 124 ----------------------
 125
 126 The usb-host driver has a bunch of properties to specify the device
 127 which should be passed to the guest:
 128
 129   hostbus=<nr> -- Specifies the bus number the device must be attached
 130   to.
 131
 132   hostaddr=<nr> -- Specifies the device address the device got
 133   assigned by the guest os.
 134
 135   hostport=<str> -- Specifies the physical port the device is attached
 136   to.
 137
 138   vendorid=<hexnr> -- Specifies the vendor ID of the device.
 139   productid=<hexnr> -- Specifies the product ID of the device.
 140
 141 In theory you can combine all these properties as you like.  In
 142 practice only a few combinations are useful:
 143
 144   (1) vendorid+productid -- match for a specific device, pass it to
 145       the guest when it shows up somewhere in the host.
 146
 147   (2) hostbus+hostport -- match for a specific physical port in the
 148       host, any device which is plugged in there gets passed to the
 149       guest.
 150
 151   (3) hostbus+hostaddr -- most useful for ad-hoc pass through as the
 152       hostaddr isn't stable, the next time you plug in the device it
 153       gets a new one ...
 154
 155 Note that USB 1.1 devices are handled by UHCI/OHCI and USB 2.0 by
 156 EHCI.  That means a device plugged into the very same physical port
 157 may show up on different buses depending on the speed.  The port I'm
 158 using for testing is bus 1 + port 1 for 2.0 devices and bus 3 + port 1
 159 for 1.1 devices.  Passing through any device plugged into that port
 160 and also assign them to the correct bus can be done this way:
 161
 162     qemu -M pc ${otheroptions}                               \
 163         -usb                                                 \
 164         -device usb-ehci,id=ehci                             \
 165         -device usb-host,bus=usb-bus.0,hostbus=3,hostport=1  \
 166         -device usb-host,bus=ehci.0,hostbus=1,hostport=1
 167
 168 enjoy,
 169   Gerd
 170
 171 --
 172 Gerd Hoffmann <kraxel@redhat.com>