1. 10 Sep, 2013 1 commit
  2. 08 Apr, 2013 2 commits
  3. 19 Feb, 2013 4 commits
  4. 12 Jan, 2013 1 commit
  5. 08 Jan, 2013 1 commit
    • Hans de Goede's avatar
      usbredir: Add support for buffered bulk input (v2) · b2d1fe67
      Hans de Goede authored
      Buffered bulk mode is intended for bulk *input* endpoints, where the data is
      of a streaming nature (not part of a command-response protocol). These
      endpoints' input buffer may overflow if data is not read quickly enough.
      So in buffered bulk mode the usb-host takes care of the submitting and
      re-submitting of bulk transfers.
      Buffered bulk mode is necessary for reliable operation with the bulk in
      endpoints of usb to serial convertors. Unfortunatelty buffered bulk input
      mode will only work with certain devices, therefor this patch also adds a
      usb-id table to enable it for devices which need it, while leaving the
      bulk ep handling for other devices unmodified.
      Note that the bumping of the required usbredir from 0.5.3 to 0.6 does
      not mean that we will now need a newer usbredir release then qemu-1.3,
      .pc files reporting 0.5.3 have only ever existed in usbredir builds directly
      from git, so qemu-1.3 needs the 0.6 release too.
      Changes in v2:
      -Split of quirk handling into quirks.c
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
  6. 01 Nov, 2012 3 commits
    • Hans de Goede's avatar
      usb: Add packet combining functions · a552a966
      Hans de Goede authored
      Currently we only do pipelining for output endpoints, since to properly
      support short-not-ok semantics we can only have one outstanding input
      packet. Since the ehci and uhci controllers have a limited per td packet
      size guests will split large input transfers to into multiple packets,
      and since we don't pipeline these, this comes with a serious performance
      This patch adds helper functions to (re-)combine packets which belong to 1
      transfer at the guest device-driver level into 1 large transger. This can be
      used by (redirection) usb-devices to enable pipelining for input endpoints.
      This patch will combine packets together until a transfer terminating packet
      is encountered. A terminating packet is a packet which meets one or more of
      the following conditions:
      1) The packet size is *not* a multiple of the endpoint max packet size
      2) The packet does *not* have its short-not-ok flag set
      3) The packet has its interrupt-on-complete flag set
      The short-not-ok flag of the combined packet is that of the terminating packet.
      Multiple combined packets may be submitted to the device, if the combined
      packets do not have their short-not-ok flag set, enabling true pipelining.
      If a combined packet does have its short-not-ok flag set the queue will
      wait with submitting further packets to the device until that packet has
      Once enabled in the usb-redir and ehci code, this improves the speed (MB/s)
      of a Linux guest reading from a USB mass storage device by a factor of
      1.2 - 1.5.
      And the main reason why I started working on this, when reading from a pl2303
      USB<->serial converter, it combines the previous 4 packets submitted per
      device-driver level read into 1 big read, reducing the number of packets / sec
      by a factor 4, and it allows to have multiple reads outstanding. This allows
      for much better latency tolerance without the pl2303's internal buffer
      overflowing (which was happening at 115200 bps, without serial flow control).
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
    • Gerd Hoffmann's avatar
      usb/ehci: add sysbus variant · e433785a
      Gerd Hoffmann authored
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
    • Gerd Hoffmann's avatar
  7. 05 Oct, 2012 1 commit
  8. 12 Jul, 2012 1 commit
    • Gerd Hoffmann's avatar
      usb: add usb attached scsi emulation · 0f58f68b
      Gerd Hoffmann authored
      $subject says all.  First cut.
      It's a pure UAS (usb attached scsi) emulation, without BOT (bulk-only
      transport) compatibility.  If your guest can't handle it use usb-storage
      The emulation works like any other scsi hba emulation (eps, lsi, virtio,
      megasas, ...).  It provides just the HBA where you can attach scsi
      devices as you like using '-device'.  A single scsi target with up to
      256 luns is supported.
      For now only usb 2.0 transport is supported.  This will change in the
      future though as I plan to use this as playground when codeing up &
      testing usb 3.0 transport and streams support in the qemu usb core and
      the xhci emulation.
      No migration support yet.  I'm planning to add usb 3.0 support first as
      this probably requires saving additional state.
      Special thanks go to Paolo for bringing the qemu scsi emulation into
      shape, so this can be added nicely without having to touch a single line
      of scsi code.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
  9. 07 Jun, 2012 2 commits