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
