[Qemu-devel] USB hardware simulation in external process

[Daniel Mack <zonque@gmail.com>]

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.

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