[Qemu-devel] USB hardware simulation in external process

[Qemu-devel] USB hardware simulation in external process

[Daniel Mack]

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

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

[Gerd Hoffmann]

On 06/11/12 16:48, 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.

It's already there.  Have a look at usbredir.

http://hansdegoede.livejournal.com/11006.html

usbredir a library and network protocol for redirecting usb devices over
the network.  Intended use case is allow accessing usb devices remotely,
i.e. allow the virtual machine running somewhere in the cloud access usb
devices plugged into the local workstation.

But of course you can alot of other stuff with it by simply
hacking/replacing the server side:  Logging what the guest machine is
doing, emulate something, ...

HTH,
  Gerd

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

[Dor Laor]

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
>

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

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
>