From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeLyL-0006NH-Aw for qemu-devel@nongnu.org; Tue, 12 Jun 2012 03:57:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeLyD-0004SW-9V for qemu-devel@nongnu.org; Tue, 12 Jun 2012 03:57:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeLyD-0004RT-0y for qemu-devel@nongnu.org; Tue, 12 Jun 2012 03:56:57 -0400 Message-ID: <4FD6F645.5070603@redhat.com> Date: Tue, 12 Jun 2012 10:56:53 +0300 From: Dor Laor MIME-Version: 1.0 References: <4FD6053D.6010005@gmail.com> In-Reply-To: <4FD6053D.6010005@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] USB hardware simulation in external process Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel Mack Cc: qemu-devel@nongnu.org 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 >