hansdegoede | Entries tagged with spice

At the end of 2013 I've spend 2 full months working on getting XHCI streams support and the UAS driver in the Linux kernel, which uses streams into shape. With the release of the 3.15 kernel this work now is available for end users to use.

This is good news for anyone who cares about performance of USB connected harddisks / ssds. The old usb mass-storage protocol is well known for its poor performance. UAS however allows NCQ and thus allows effectively using the full USB-3 bandwidth. If you've an UAS capable harddisk enclosure then all you need is a 3.15 kernel build with the UAS driver enabled and you should instantly get better performance. Note that most harddisk enclosures, including USB-3 enclosures do not support UAS, so if you want to use UAS double check before buying a harddisk enclosure.

One use-case of UAS I love is to have a 2.5" ssd with a full Fedora rawhide install with me so that when people ask me about hardware compatilibty issues they are having, I can simply plug in the ssd to there laptop boot rawhide and see if having the latest kernel + xorg fixes things. For a decently priced UAS capable 2.5" hdd enclosure search ebay for: "sedna usb 3.0 2.5 inch hdd enclosure". when shopping for UAS enabled devices, always check that the device description mentions UAS or UASP.

Besides UAS support, the 3.15 kernel also features support for using USB-3 bulk streams from userspace through usbfs. To use this you need the just released libusb-1.0.19 release. One use case of USB-3 bulk streams from userspace is using these for usb-redirection in qemu. With the upcoming 2.1 qemu release this will be supported allowing the use if usb-3 redirection with uas devices from within a qemu vm. This will be supported with both qemu's host usb redirection, as well as spice's network usb redirection. This means that starting with qemu-2.1 qemu's USB redirection features full USB-3.0 compatibility.

Xorg without root rights is now available in Fedora rawhide. Currently the suid root wrapper which is intended for ums compatbility is configured to run the server as root by default even on kms using setups, because starting Xorg as a normal user requires the display manager to set up its session and tty as it can no longer do that itself, and non of the display managers are ready to do this yet.

Still you can test running Xorg as user if you want, create a file called /etc/X11/Xwrapper.config with the following line in there: "needs_root_rights = auto" the default for "needs_root_rights" currently is "yes" rather then "auto" because of the display managers not being ready yet. Then switch to a text console (ctrl + alt + F2) log in as a regular user and run: "startx". Now do "ps aux" and you should see a (second) Xorg process running as a normal user.

If you're running rawhide and have some time to spare I would appreciate it if you can give this a try, and let me know if you see any issues running Xorg as normal user. Don't forget to remove the /etc/X11/Xwrapper.config file you've created after testing so that you don't break your graphical login screen.

The last few months I've been working on making Xorg run without root rights. Xorg has traditionally always been suid root because it needed direct hardware access. With the advent of kms all hardware access is done by the kernel, so the primary reason for the X server running with root rights is no longer relevant.

Yet the current xserver still need root rights for 3 reasons:

1. Access to /dev/input/event* and /dev/dri/card*

Wayland needs this to, so a while ago systemd-logind has grown an API to allow a process inside a session to become the session controller, and get filedescriptors for these device nodes over dbus.

Some people may think that this is overkill and that simply opening up the permissions on the device nodes would be enough, but that is not true. For /dev/input/event* nodes we want a manager process to revoke the access of a session becoming inactive, so that it cannot stick around and snoop input events destined for another session. And for /dev/dri/card* nodes root rights are necessary to become the drm master.

2. Setting up a session and a tty, ie VT_SETMODE VTPROCESS

Since creating a new session requires root rights this is left to the process starting the X server, usually the display manager. When the X server is started from a text login on a virtual terminal using startx, it simply takes over the existing session on that vt. As for VT_SETMODE VTPROCESS that will work as a normal user too as long as that user owns the tty (and setting tty ownership is part of setting up a proper session).

3. Logging to /var/log/Xorg.#.log

Xorg 1.16 will log to ~/.local/share/xorg/Xorg.#.log when started as non root.

Driver changes

With systemd-logind now managing device node access, we also need a bunch of driver changes as many Xorg drivers used to directly open device nodes themselves. Xorg 1.16 introduces server-managed fds, when:

the X server is compiled with systemd-logind support; and

systemd-logind is available; and

the driver used supports server-managed fds

Then the server will manage the filedescriptor for the relevant /dev/... device node, and pass it into the driver at init time. The necessary driver changes are quite minimal, see this video driver example and this input driver example.

VT switching

For switching away (vt-leave) from the VT on which the X server is running, the X server will keep using the VT_PROCESS VT mode, so everything can be shutdown safely before the VT switch happens. For server-managed fds the server will do a DRM_DROP_MASTER for video devices, and close the fd for input devices.

When switching back to the X server VT, systemd-logind will pass in new fds for input devices and call DRM_SET_MASTER for video devices asynchronously from the VT enter. So when systemd-logind is used the VT enter sequence is a bit differently, the VT enter signal the X server receives is ignored. Instead the X server waits till systemd-logind has signalled it is the drm master again for all the server-managed video device nodes. Filedescriptors received before the server is drm master again are cached, and the input devices are activated immediately after the video nodes are, fds received after this are activated immediately.

User-space modesetting (UMS) compatibility

When the Xorg binary is no longer suid root, UMS drivers will not work. To solve this there is a new suid-wrapper called Xorg.wrap which is suid root, when installed this wrapper will get called in stead of the real X server, and it will check if there are KMS capable cards in the system, if KMS capable cards are found it will drop all elevated rights and execute the X server as a normal user. If no KMS capable cards are found it will execute the X server with root rights, allowing old UMS drivers, such as the proprietary drivers for some cards, or the vesa driver to work.

Use of this wrapper is optional and security concious users who have a KMS capable system will be able to do "yum remove xorg-x11-server-wrapper", or their distro's equivalent.

Sunday May 4th Revspace is organizing a workshop on reverse engineering USB protocols of devices with proprietary protocols.

Reverse engineering protocols is fun! It's like a puzzle, and if there's software out there that can solve the puzzle, your brain can do it too.

We'll be taking a look at reverse engineering the protocols on USB-connected devices. Too many of these devices still come with windows drivers only, and use an undocumented protocol. Figuring out those protocols is often a lot easier than you might think, and so is writing a simple driver.

If you want to participate in this workshop, bring a Linux laptop, preferably with a virtual machine with a Windows guest OS. If you have an exotic USB device that only has a Windows driver, please bring that too.

For more details see: https://revspace.nl/UsbProtoReverseEngineeringWS2

Today is spice test day! For details see: https://fedoraproject.org/wiki/Test_Day:2013-05-30_Spice

Now stop reading Fedora planet, and go and test Spice!

Hi all,

Spice by default is intended for use over the network, and as such uses image compression, which is not really useful when only using a vm locally. So if you've vms which you only use locally you may want to turn the image-compression off. To do this, do: "virsh edit <vm-name>", then locate the
section starting with "<graphics", ie in my case this is a single line section looking like this:

   <graphics type='spice' autoport='yes'/>

To disable image-compression, add the following 2 lines too this section, changing it to a multi-line section if necessary:

     <image compression='auto_glz'/>
      <streaming mode='filter'/>

So in my example this changes the graphics section into:

   <graphics type='spice' autoport='yes'>
      <image compression='off'/>
      <streaming mode='off'/>
    </graphics>

Note that the "/>" at the and of the line starting with "<graphics" has been changed into just a ">", since this is a multi-line section now!

Then shut off the vm, power it up again and enjoy your faster local graphics.

Hi all,

So far if you wanted to configure a Linux guest with multiple monitors this required adding multiple qxl cards to the vm and manually putting an xorg.conf in place.

Since Fedora-18 however Spice supports having multiple monitors on a single qxl device, so with any Linux vm you can now easily add / remove / resize monitors on the fly, depending on your configuration you may need some small tweaks to enable this on the guest and host side.

On the guest side F-19 should work out of the box, in F-18 the xorg-x11-drv-qxl driver was build against an older spice-protocol package, causing it to not have support for this new feature enabled, this is fixed in this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=422914 , which will hit updates-testing soon: https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.0-2.fc18?_csrf_token=bef3ee718fbf6ddde4d40197a7f4c9c83a5d5110 in the mean time you can install it inside your Fedora-18 guest from koji if you want to test this feature

On the host side the qxl device in vms created in F-18 report itself with a pci-revision of 3, where as a revision of 4 indicates support for this new feature. But qemu in F-18+ does support this feature, we simply need to tell it to advertise this to the guest. Do to this do "virsh edit <vm-name>" and then at the top of the xml change the "<domain type='... >" line to:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

and add the following at the end, above the "</domain>" line:

<qemu:commandline>
<qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.revision=4'/>
    </qemu:commandline>

          Note this is not necessary for vms created in F-19

To use this new feature, shut off and then power on the vm, then connect to the vm using remote-viewer. ie: "remote-viewer spice://localhost:5900", and log into an X-session. Once logged into the X-session, go to the "View -> Displays" menu, you can now enable additional monitors there. Also note that you can freely resize all the client windows and the guest monitors will be adjusted to match the client window size(s).

Enjoy! And please let us know about any issues you find.

I'm happy to announce the existence of libusbx, a fork of libusb,. a bit late I must admit, as libusbx has been available for a while now, but as one of the people behind it I still wanted to mention it on my blog.

The libusbx fork was started by various libusb-1.0 developers (almost all of them), because the official maintainer of libusb-1.0 refused to do any stable / tarbal releases for over 18 months and in general was very slow with merging new developments and fixes.

Anyways, lets not look backwards, but forwards towards what looks to be a bright new future with libusbx :)

For more info on libusbx see the libusbx wiki.

I'm currently working on moving Fedora over to libusbx, you can find the Rename Review Request here.

usbredir-0.3.3, spice-0.10.1, spice-gtk-0.9 have been recently released upstream and are available in Fedora-16 updates[-testing] and are chock-full of new USB redirection features & fixes:

Improved compatibility various usb mass storages devices which would not work before are working now
You no longer need to run spicy as root to use USB redirection, when running as a normal user you will now get a PolicyKit dialog asking you for the root password. You can change this by editing: /usr/share/polkit-1/actions/org.spice-space.lowlevelusbaccess.policy and setting <allow_active> to "yes". Note that this will give any local users of your machine FULL access to any USB devices plugged in!
You can now redirect already plugged in devices / un-redirect devices without unplugging them, go to the
Input menu and click "Select USB Devices for redirection".
Filtering for auto-redirection, you can now specify a filter for auto redirection using --spice-usbredir-auto-redirect-filter=<filter-string>. Standard a filter is in place to avoid redirection of HID devices, so that if you've a glitch on your USB bus, or plug a mouse into a laptop it no longer gets swallowed by the vm making it unavailable to the client.

I'll be at FOSDEM this weekend, and I'll give a talk about Spice, sheets here. As well as a talk about USB redirection, sheets here. Besides me there will be 4 other people from the Spice team there, be sure to also watch their talks about XSpice and Boxes. If you have any question about Spice, or just want talk to us, FOSDEM is an excellent opportunity to do so!

While I'm plugging talks @FOSDEM, there will also be lots of other talks from Red Hat speakers.

Enjoy, and be sure to send any feedback you may have my way!

Various people have been asking how to run qemu with spice when launching qemu directly, rather then through libvirt + virt-manager. So here is a quick howto.

*** The basics ***

Besides adding the usual qemu cmdline options to make it find the harddisk to boot from, have a NIC, soundcard, etc. in order to add spice add the following to the cmdline:
-vga qxl -spice port=5932,disable-ticketing

After launching qemu with this, you can connect to it with spicy (new gtk based client) or spicec (old libX11 client), like this
(their cmdline syntax is compatible):
spicy -h localhost -p 5932

*** Enabling the agent channel ***

To really enjoy spice, with all its features like copy paste between client and guest, and client mouse mode (mouse cursor drawn by client, so 0 mouse lag), you need to install the qxl graphics driver and spice-agent in the guest, *and* enable the agent channel between the guest and the client, to do this add the following options to the qemu cmdline:
-device virtio-serial \
-chardev spicevmc,id=vdagent,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0

*** Enabling support for usb redirection ***

If you're running qemu under Fedora-16 (or newer), or have build it from source with usbredirection support as explained in my previous blog post, then you can also let spice redirect usb devices from your client to the vm, to enable this you will first need to enable usb2 emulation in qemu, download this file, and drop it in /etc/qemu. And at the following to the qemu cmdline:
-readconfig /etc/qemu/ich9-ehci-uhci.cfg

Then to create 3 usbredir ports into which the client can then "plug" redirected devices add the following:
-chardev spicevmc,name=usbredir,id=usbredirchardev1 \
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3 \
-chardev spicevmc,name=usbredir,id=usbredirchardev2 \
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=3 \
-chardev spicevmc,name=usbredir,id=usbredirchardev3 \
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3 \

The debug=3 is not strictly necessary, but it gives some useful messages without flooding the qemu console with messages. Note that you can also create more / less then 3 usbredirection usb "ports", how to do this is left as an
excercise to the reader :)

To use the usb redirection connect to the vm with spicy running as root, so that it can access the device nodes under /dev/bus/usb.

Select the options menu entry and make sure that the "auto redirect newly plugged in USB devices" option is checked. After this make sure the vm has keyboard focus (so close the options menu), plug in a new USB device and watch it show up in your vm :) Feel free to yank it out again at any time :)

If you plug in a device while the vm does not have keyboard focus, it will not get redirected, so you can use usb devices
normally as long as you don't have the vm focussed when you plug them in.

Enjoy, and be sure to send any feedback you may have my way!

Hi,

Here is a little howto for building qemu + spice with usbredirection from source, for those of you who are not running Fedora 16.

The below instructions assume:

That you are familiar with building things from source
That you are running the 64 bit version a fairly recent Linux distribution
That you want to override you distro installed version of various bits with the bits build from source, this is necessary to ensure that everything builds and runs linked against the correct version of various libs.
That using a distribution with a multilib setup where 64 bit libraries go into /usr/lib64. If you are using a distro which puts 64 bits libraries under /usr/lib rather then /usr/lib64 (for example Debian or ubuntu), you need to replace /usr/lib64 with /usr/lib in all commands below

*** Step 1 Building libusb ***

First of all you will need libusb from git for now, hopefully there will soon be an offfical 1.0.9 release you can use instead. To build libusb from git do:

git clone git://libusbx.git.sourceforge.net/gitroot/libusbx/libusbx
cd libusbx
./autogen.sh --prefix=/usr --libdir=/lib64
make
sudo make install

*** Step 2 building usbredir ***

Next you will need to build usbredir itself for the usbredirparser and usbredirhost libraries, download it here, then do:

tar xvfj usbredir-0.4.3.tar.bz2
cd usbredir-0.4.3
make -j2 PREFIX=/usr LIBDIR=/usr/lib64
sudo make PREFIX=/usr LIBDIR=/usr/lib64 install

*** step 3 building spice-protocol ***

For usbredir support we need version >= 0.10 of spice-protocol, download it here, then do:

tar xvfj spice-protocol-0.10.1.tar.bz2
cd spice-protocol-0.10.1
./configure.sh --prefix=/usr --libdir=/usr/lib64
make -j2
sudo make install

*** step 4 building spice[-server] ***

For usbredir support we need version >= 0.10 of spice, download it here, then do:

tar xvfj spice-0.10.1.tar.bz2
cd spice-0.10.1
./configure --prefix=/usr --libdir=/usr/lib64 --enable-smartcard
make -j2
sudo make install

*** Step 5 building qemu ***

The core usbredir code is already in the qemu-0.15.0 upstream release, but some bits needed for integrating it
with spice are missing. Besided that it is also good to get a version with some recent spice fixes included, so
we will again use a git tree for this:

git clone git://people.freedesktop.org/~jwrdegoede/qemu
cd qemu
git checkout -B qemu-kvm-1.0-usbredir qemu-kvm-1.0-usbredir
./configure --prefix=/usr --enable-smartcard-nss --enable-smartcard --enable-spice --target-list=x86_64-softmmu
make -j2
# do not do make install, this will replace the versions of seabios & friends installed by your distro with (quite old non
# working) versions of seabios which are still part of the qemu git tree (someone ought to fix this one of these days)
sudo install -m0755 -p x86_64-softmmu/qemu-system-x86_64 /usr/bin

*** Step 6 building spice-gtk with usbredir support ***

Get spice-gtk version 0.11 or newer here.

tar xvfj spice-gtk-0.11.tar.bz2
cd spice-gtk-0.11
./configure --prefix=/usr --libdir=/usr/lib64
make -j2
sudo make install

*** All done ***

All done, to enjoy the usbredir support you need to pass some extra qemu options on the qemu cmdline, see my next blogpost for details.

I'm happy to announce the availability of USB redirection support in SPICE in Fedora 16. Unfortunately the virtmanager bits are not there yet. So if you want to try this you need to configure it manually. This howto assumes
a fully up2date F-16 with spice-gtk from updates-testing installed.

First create a virtual machine as usual, using virt-manager, select spice as display type and qxl as video card model,
when asked if you want to enable the agent channel, say yes.

When done, close virt-manager and edit the relevant /etc/libvirt/qemu/foo.xml file and add the following lines at the end, above the "</devices>" line:

    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/>
    </controller>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='4'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='5'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='6'/>
    </redirdev>

Note that the slot='0x08' needs to be one higher then the higest pci slot already in use, so if you've more
pci devices in your config then me you may need to make this higher.

Then close down any virtual machines you may have open, and restart libvirt:
service libvirtd restart

Now start the vm with virt-manager, open it, select the details view, click on Display Spice and lookup and remember the port mentioned there (this will be 5900 if it is the only running vm).

Close virt-manager, and connect to the vm with spicy, like this:
spicy -h localhost -p 5900

Where 5900 should be replaced by the port the vm is actually running on.

Select the options menu entry and make sure that the "auto redirect newly plugged in USB devices" option is checked. After this make sure the vm has keyboard focus (so close the options menu), and plug in a new USB device. You will now
get a PolicyKit dialog asking you for your root password, this is needed since redirecting USB devices requires access the device nodes under /dev/bus/usb. Once you've (correctly) typed your root password, watch the USB device show up in your vm :) Feel free to yank it out again at any time :)

If you plug in a device while the vm does not have keyboard focus, it will not get redirected, so you can use usb devices
normally as long as you don't have the vm focussed when you plug them in.

If you want to redirect already plugged in devices, or un-redirect redirected devices without unplugging them go to the
Input menu and click "Select USB Devices for redirection".

Enjoy, and be sure to send any feedback you may have my way!

Note (Feb 1 2012): this blog post has been updated to:

Use the new usbredir support in libvirt, rather then to directly inject qemu cmdline from the libvirt xml file using the qemu:commandline syntax.
Reflect the use of PolicyKit rather then needing to run the client as root
The new USB device selection widget

I'm very happy to announce the first official release of the usbredir code: usbredir-0.3.tar.bz2.

usbredir is a protocol for redirection USB traffic from a single USB device,
to a different (virtual) machine then the one to which the USB device is
attached. See usb-redirection-protocol.txt for the description / definition
of this protocol.

With the official 0.3 release the protocol is now frozen (only extensions
advertised through capabilities can be added from now on).

This package contains a number of libraries to help implementing support
for usbredir and a few simple usbredir applications:

usbredirparser:
A library containing the parser for the usbredir protocol

usbredirhost:
A library implementing the usb-host (*) side of a usbredir connection.
All that an application wishing to implement an usb-host needs to do is:
* Provide a libusb device handle for the device
* Provide write and read callbacks for the actual transport of usbredir data
* Monitor for usbredir and libusb read/write events and call their handlers

*) The side to which the actual USB device is attached, also see the
definitions section in usb-redirection-protocol.txt

usbredirserver:
A simple tcp server usb-host, using usbredirhost

usbredirtestclient:
A small testclient for the usbredir protocol over tcp, using usbredirparser

Note that the usb-guest side is missing from this, this will be part of qemu. I've all my qemu usb changes except for the actual usbredir usbdevice itself queued up for merging upstream. You can find a version of qemu with usbredir support in my git repo here. See previous posts for compilation and usage instructions

I've pushed an updated version of my usb-redirection code to my git repo. The biggest change is that the usbredir device now is a chardev frontend. Which means that the way to use it has changed. Also there now is proper emulation of companion controllers for the ehci code. Here is an example cmdline for using both:

-device usb-ehci,addr=0b.2,multifunction=on,id=ehci0 -device piix3-usb-uhci,addr=0b.0,multifunction=on,masterbus=ehci0.0,firstport=0
-device piix3-usb-uhci,addr=0b.1,multifunction=on,masterbus=ehci0.0,firstport=2
-chardev socket,id=usbredirchardev,host=localhost,port=4000
-device usb-redir,chardev=usbredirchardev,id=usbredirdev

There have also been some usbredir protocol changes, so you need to update and rebuild your usbredir clone too. I hope to release a usbredir-0.1.0 with a frozen protocol soon.

Friday July 22 we're organizing a workshop on reverse engineering
USB protocols of devices with proprietary protocols.

Reverse engineering protocols is fun! It's like a puzzle, and if there's
software out there that can solve the puzzle, your brain can do it too.

We'll be taking a look at reverse engineering the protocols on USB-connected
devices. Too many of these devices still come with windows drivers only, and
use an undocumented protocol. Figuring out those protocols is often a lot
easier than you might think, and so is writing a simple driver.

If you want to participate in this workshop, bring a Linux laptop,
preferably with a virtual machine with a Windows guest OS. If you have an
exotic USB device that only has a Windows driver, please bring that too.

This workshop will be given by Bert Vermeulen and Hans de Goede. Bert has
reverse engineered and written drivers for various USB logic analyzers for
sigrok: http://sigrok.org . Hans has reverse engineered and written drivers
for various USB webcams for the Linux kernel and for digital photoframes
for libgphoto2.

Program:
19:00 Welcome, drinks
19:30 Start of the workshop Bert & Hans give a short intro on USB protocol
      principles and a short demo of sniffing and interpreting usb traffic
20:15 Time to get your hands dirty, start reverse engineering your own USB
      device, or one of the devices provided. Your hosts will be walking
      around to answer questions and help you pass any speedbumps you
      encounter.
late: Time to go home?
really late: Chances are your hosts will want to go home at this time, hint
             hint.

Location:

This workshop will be held in the hackerspace Revelation Space in The Hague:
http://revspace.nl/

Registration:

Registration is not mandatory, but in order to have an idea of how many
people will be coming we kindly request you to send an email to
hdegoede@redhat.com if you're going to attend.

Hi All,

I've been working on USB redirection over the network for qemu / spice for a while now. And I'm happy to report I've something which is good enough to invite others to test it. In the mean time Gert Hoffmann (kraxel) has been working on cleaning up the EHCI support which was submitted to the qemu-devel list about a year ago, making it suitable to get merged. My qemu git tree is based on Gert's tree, so it has prelimary USB2 support too. Note that the USB2 support works best when used together with the network redirection code over localhost, that seems to be more reliable at the moment then using qemu's direct usb host redirection code.

So if you want to play around with this here are some installation instructions. These instructions assume a 64 bit Red Hat or Fedora installation, with libusb-1.0.so.0 in /lib64. If you've a 32 bit installation or are using a distribution which does not use /[usr/]lib64 for 64 bit installations (such as Debian and Ubuntu) replace /lib64 with /lib in the below instructions.

First of all you will need my version of libusb, which is has a new libusb_get_device_speed function, this is intended
to go upstream sometime soon. But first upstream needs to get to long awaited 1.0.9 out the door. To install my (fully compatible) libusb version do:
git clone git://anongit.freedesktop.org/~jwrdegoede/libusb
cd libusb
git checkout usbredir
./autogen.sh
./configure --prefix=/usr --libdir=/lib64
make
sudo make install

With the new libusb in place, it is time to build the non qemu parts of the usbredir code
(a standalone server, as well as the usbredir protocol parser and host libraries):
git clone git://anongit.freedesktop.org/~jwrdegoede/usbredir
cd usbredir
make PREFIX=/usr LIBDIR=/usr/lib64
sudo make PREFIX=/usr LIBDIR=/usr/lib64 install

And now lets build qemu with usbredir support (note I enable spice + spices smartcard support here, since that is
what I use in my day to day testing, this is not strictly needed).
git clone git://anongit.freedesktop.org/~jwrdegoede/qemu
cd qemu
git checkout usbredir
./configure --prefix=/usr --enable-smartcard-nss --enable-smartcard --enable-spice --target-list=x86_64-softmmu
make
sudo install -m0755 -p x86_64-softmmu/qemu-system-x86_64 "/usr/bin"

Note do not use make install, this will also install the BIOS roms from qemu git which are outdated, this assumes that you already have a recent qemu installed and will be using the BIOS roms from that version.

Now start qemu with all the options you use normally and "-usb" or "-usb -device usb-ehci" for USB2 support. To test the network redirection, start the usbredirserver in another terminal, lets say you want to redirect a usb device with vid:pid
045e:0772, then start usbredirserver like this:
usbredirserver 045e:0772

And then in the qemu monitor cmdline type:
usb_add tcp-redir:localhost:4000

Notes:
1) replace localhost with the ip or hostname of the other machine if you're actually testing this over the network
2) you can start multiple servers to redirect multiple devices on the same machine, add " -p 4001" to start a second
server on port 4001, and make the 4000 4001 in the usb_add command
3) To unplug a device do a usb_del with the exact same arguments as you passed to the usb_add command

If you're interested in the network protocol used for the usb redirection, see:
http://cgit.freedesktop.org/~jwrdegoede/usbredir/tree/usb-redirection-protocol.txt

Regards,

Hans