[Spice-devel] Questions on usbredir + XSpice

[Alon Levy]

On 08/06/2014 02:02 PM, Hans de Goede wrote:
> Hi,
> 
> On 08/06/2014 08:02 AM, Alon Levy wrote:
>> On 08/05/2014 10:52 PM, Jeremy White wrote:
>>> While I'm researching, I thought I'd look into the next challenge for
>>> XSpice - usb device redirection.
>>>
>>> It faces similar challenges to the CAC card stuff.  That is, my sense is
>>> that the usbredir library and utility set is all about reading client
>>> machine USB device information and relaying it through to qemu, which
>>> then exposes it as a 'real' device to the guest OS.
>>>
>>> Again, with XSpice, we don't have qemu :-(.
>>>
>>> Ideally, we'd find some mechanism to inject a usb device into the system
>>> running XSpice.
>>>
>>> I've done some further research, and the usbip project would seem
>>> useful.  It was here:
>>>    http://usbip.sourceforge.net/
>>> but apparently is now in the kernel.
>>>
>>> If we use that, then the challenge would appear to be translating the
>>> protocols.
>>>
>>> Alternates:
>>>   1.  Use usbip end-to-end
>>>        I'd like to avoid this; there are benefits to having all spice
>>> traffic go over the same channel
>>>   2.  ???  Insight appreciated <grin> ???
>>>       (I can't help but feel there are other methods for simulating a
>>> USB device, but I'm fairly ignorant of this space).
>>>
>>
>> 2. Teach usbredir to use a kernel without a vm.
> 
> Yes that would be the rigt solution to this, there are use-cases outside
> of Xspice for this too. The solution you're looking for here is to
> wtite a virtual hcd device (driver) for the kernel talking the

So something like http://sourceforge.net/projects/usb-vhci/ ?

Or if that is a bad starting point, which one is?
ehci-hcd.c / ohci-hcd.c / other? (looking at kernel/drivers/usb/host)

> usbredir protocol, so basically do what the server side usbip bits
> do, but then with a new protocol.
> 
> I would advice against going for a protocol translater, your time would
> better spend on doing this properly right away.
> 
> I would certsainly be interested in testing and reviewing patches
> for this and help getting them added to the upstream kernel.
> 
> Regards,
> 
> Hans
>