From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik Rull Subject: Re: USB EHCI patch for 0.14.0? Date: Wed, 09 Mar 2011 23:48:59 +0100 Message-ID: <4D7803DB.6050106@rdsoftware.de> References: <0NZZCL-1PxLUf03cg-0000cf@icpu525.kundenserver.de> <4D77A6E7.3080505@cisco.com> <4D77F0E3.6070500@rdsoftware.de> <4D77FBAD.8020703@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: David Ahern Return-path: Received: from moutng.kundenserver.de ([212.227.126.171]:54248 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751253Ab1CIWtm (ORCPT ); Wed, 9 Mar 2011 17:49:42 -0500 In-Reply-To: <4D77FBAD.8020703@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: David Ahern wrote: > > > On 03/09/11 14:28, Erik Rull wrote: >> David Ahern wrote: >> I've tried it long time ago with kvm-88, but there it was working but >> extremely slow. (At least the mouse was reacting there) > > I thought you tried the EHCI patch against a recent qemu-kvm version -- > like December 2010 or January 2011. Yes, this time I patched against 0.14.0, I misunderstood your question, sorry. My last attempt before that was kvm-88. >> Hm, okay. >> As far as I understood it, the auto-add feature should be similar to the >> USB 1.1, right? It seems to work basically but not fully - the system is >> somehow slowed down, maybe the polling timer is too fast? (I will play a >> little bit with that and review and compare as well the auto routine) >> >> And the usb-tablet should be an uhci-emulated component, that should >> then not interfere with the ehci-emulation, right? > > My proposal from July 2010 was to have emulated devices state their > version and have host devices try EHCI then UHCI. This means that the > tablet device is attached to UHCI and a host USB key is attached to > EHCI. Like this: > > info usb > Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet > Device 1.1, Port , Speed 480 Mb/s, Product DT 101 II > (qemu) > > That's what the patch I sent does. > > EHCI does have a lot higher frame rate and in its current form does have > a noticeable impact on CPU usage when devices are connected and one of > the lists is activated. If the OS deactivates the controller when there > is nothing to do (e.g., not actively talking to the device), cpu usage > goes down. Thanks for the explanation! > I just tried a few scenarios with the X and V versions of those GUI > based guests and an external key attached to EHCI bus worked fine and > the usb tablet also worked fine. > > I did notice some differences in command syntax. For instance, my > scripts still use the older -usbdevice tablet syntax and I did not see > the USB stall message. Switching to '-device usb-tablet' did generate > the message at boot (though overall it seems to be harmless). > > Nothing fancy with the setup -- ide drive, virtio or e1000 networking, > ac97 sound, no-hpet and usb tablet devices. > > In the time it took to write this response about 900MB was transferred > to the usb key at about 1.7-1.8MB/sec rate. > > David I will give it another try tomorrow. I use -usb -device usb-tablet -device usb-host The last parameter for the auto-add to the guest I will also try the old parameter syntax. What does the no-hpet option do? Might this be somehow significant regarding the performance? Best regards, Erik P.S. When EHCI was active today without tablet and without auto-add I got a transfer rate of ~5MByte/sec from USB key to the HDD.