Re: [Qemu-devel] USB hardware simulation in external process

[Dor Laor <dlaor@redhat.com>]

On 06/11/2012 05:48 PM, Daniel Mack wrote:
> Hey,
>
> I'm thinking about adding a USB hardware proxy that allows communication
> with an external server process which in turn simulates USB devices.
>
> I'm new to the internals of QEMU, so what I'm sharing here might already
> have been discussed a gazillion times. In that case, just drop me some
> pointers.
>
> I want to try and outline the idea following a real-life example. As an
> USB driver kernel developer, I often face the situation that people
> report problems and send their lsusb dumps along with a description of
> kernel level misbehaviour they're seeing. Sometimes things are rather
> obvious, in other cases, it is mandatory to have hardware access to the
> device in order to reproduce and fix the issue.
>
> In a recent case[1], I chose a different approach for the first time: I
> simulated a device with a broken descriptor set by adding a dirty hack
> to an existing virtual USB device inside QEMU. This worked surprisingly
> well: the hosted kernel showed the reported behaviour and I could
> finally fix it within minutes.
>
> So that made me thinking. Wouldn't it be possible to add a communication
> layer to QEMU that connects to an external server which acts as emulator
> for all sorts of USB devices? That way, I could keep the broken device
> implementation around for later regression testing, at a place where it
> doesn't bother anyone. Thinking further, there could be a growing number
> of devices that either misbehave in a certain way or just simulate a
> certain function, and along with some test code, this could be used as
> automated function and regression test for new kernel versions. Tests
> could also include arbitrary connection/disconnection of devices to
> stress test the stack and provoke race conditions and all the like.
>
> The reason for having it hosted by an external process is to have a
> clear separation of the emulator itself and the part that throws dirt at
> the stack implementation. (It would also be possible to use a
> object-oriented scripting language for easy integration of new hardware
> models).
>
> I wonder whether such an approach is feasible and worth thinking about.
> If it is, what would be a sane communication protocol? It would need to
> be something fully bidirectional. I know there is QMP, but I'm not sure
> whether it would be usable for this purpose.

Have you looked at spice's usb redirection [1]?
If you're emulate the usb device on a separate process you can connect 
it to qemu using spice.

Regards,
Dor

[1] http://fedoraproject.org/wiki/Features/UsbNetworkRedirection

>
> Anyway, I might have totally lost track and overlooked that such things
> are already possible, or an obvious reason why this is a very bad idea
> in the first place. Just wanted to share my thoughts and ask for some
> feedback :)
>
>
> Daniel
>
> [1] http://comments.gmane.org/gmane.linux.alsa.devel/96433
>