Quoting Jaap Winius <jwinius(a)umrk.nl>:
... Anyway I guess now it's USB passthrough or bust. Or get
a board with an IOMMU.
In case anyone is ever interested, I did eventually manage to solve
this problem with a wrapper script, although not exactly the way David
Wragg explains in his blog.
With Debian squeeze, the problem is that when using virt-manager to
configure USB passthrough, it allows you to select a USB device based
on its vendorID and productID combination, which happens to be exactly
what I need. However, when passing the selected device on to the
virtual machine, the kvm command it generates is only for the
bus/device combination that the selected device is currently using.
That, combined with the lack of any hot-plug support is what was
preventing me from getting my system to work.
The solution for me was simply to bypass any methods using
virt-manager or the virsh editor to define the devices for USB
passthrough. Then, instead of using the wrapper script to modify any
devices already defined, I use it to add all of the devices I need. It
looks like this:
#!/bin/sh
exec /usr/bin/kvm `echo $* | sed 's/-vga std/-vga std -usbdevice
host:auto:*.*:0c93:1772 -usbdevice host:auto:*.*:0c93:1771/'`
Incidentally, this script has to have the same name as the executable,
which on Debian squeeze is /usr/bin/kvm. So, I called this script
/usr/local/bin/kvm, and not /usr/local/bin/qemu-kvm, like in Wragg's
blog.
Anyway, the above script allows me to start up the virtual machine
with only one (or none) of the devices attached. Then the theory is
that the Windows device driver loads some firmware into the device,
which causes it to change its product ID from 1772 to 1771, as well as
its device number. Crucially, my wrapper script doesn't care about
this device number change and the new device is also passed through to
the virtual machine. As far as I can tell, the Windows software
continues to work as expected.
Cheers,
Jaap