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

[Daniel Mack]

On 12.06.2012 09:56, Dor Laor wrote:
> 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.

(Cc: Hans)

Thanks a lot for the pointer! This sounds infact interesting and I've
had a similar server/client model in mind.

Unfortunately though, the protocol spoken by libusbredir is not exactly
what I'm looking for, as it is too "high level" for what I want to
achieve. Naturally, libusbredir was written for well-behaving devices
and skips most of the low-level USB protocol parsers, state machines and
the like. Which makes sense for getting the job done.

However, what I'm trying to do is simulate devices that misbehave
explicitly, to test how the descriptor parsers in Linux drivers deal
with them. Hence, all communication between the client and the server
should be broken down to control/interrupt/bulk/iso transfers, and the
server would need to implement all the low-level USB protocol functions
itself. In other words: the server would need to handle the same data
streams a typical firmware deals with.

Hans, would there be a way to implement this in libusbredir? I'm
thinking about a capability flag that states something like "this server
is only able to serve low-level requests". Not sure though how tricky it
would be to handle this in the QEMU client. Opinions?


Thanks,
Daniel