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

[Daniel Mack]

ping?

On 15.06.2012 17:01, Daniel Mack wrote:
> 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
>