From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShH5W-0002Jo-4o for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:20:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShH5P-0004Z9-Nd for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:20:33 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:63280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShH5P-0004YC-AI for qemu-devel@nongnu.org; Wed, 20 Jun 2012 05:20:27 -0400 Received: by bkwj10 with SMTP id j10so6305711bkw.4 for ; Wed, 20 Jun 2012 02:20:24 -0700 (PDT) Message-ID: <4FE195D3.1020004@gmail.com> Date: Wed, 20 Jun 2012 11:20:19 +0200 From: Daniel Mack MIME-Version: 1.0 References: <4FD6053D.6010005@gmail.com> <4FD6F645.5070603@redhat.com> <4FDB4E3B.4000203@gmail.com> In-Reply-To: <4FDB4E3B.4000203@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] USB hardware simulation in external process List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Hans de Goede , qemu-devel@nongnu.org, kraxel@redhat.com 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 >