qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Erik Rull <erik.rull@rdsoftware.de>
To: Reeted <reeted@shiftmail.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] USB 2.0 printer passthrough very slow
Date: Tue, 03 Apr 2012 15:33:36 +0200	[thread overview]
Message-ID: <4F7AFC30.2060207@rdsoftware.de> (raw)
In-Reply-To: <4F7AEC7D.7020701@shiftmail.org>

Hi,

please try to use the .cfg file from the docs/ directory, using this file, 
the USB printer speed is really good on my systems. Well it is still an 
emulation so you'll never get native speed, but it is far better than the 
USB 1.x emulation we had in 0.1x versions.
Best thing to test the approx. transfer speed: Plug in a fast usb key, copy 
some larger data chunks and measure the time - on the same port where you 
attach the printer.

Printing e.g. the Windows XP test page takes not really more time than on a 
native system.

Best regards,

Erik


Reeted wrote:
> Hello all,
> I have virtualized a Windows 2000 machine, using usb-passthrough as in:
>
> http://fossies.org/unix/privat/qemu-1.0.1.tar.gz:a/qemu-1.0.1/docs/usb2.txt
>
> in companion controller mode, i.e. specifying "bus=ehci.0" for both 1.1
> devices and 2.0 devices.
>
> I used "companion mode" because in my tests I had problems with two
> separate busses: attaching a 1.1 device to the emulated ehci bus was
> notifying errors of incompatible speed and would not work, while attaching
> it to the emulated 1.1 bus had another problem which I don't remember
> exactly... I think either it was not possible or qemu was crashing. But
> with companion mode it appeared to work.
>
> In my early tests I did notice that ehci emulation was rather slow: reading
> an USB flash key sequentially was yelding 6.5MB/sec (from the host it was
> much faster like 20MB/sec afair), but I guessed that would be enough for an
> USB printer. I have not actually tested if non-companion mode would be
> faster, maybe I could have tried that... If you think it would be faster
> please tell.
>
> After virtualizing Windows 2000 the problem became very apparent in printing!
> My canon IP4700 now takes 3 to 4 minutes for a print job to execute and
> clear from the queue. That's almost unusable.
>
> Note that the speed is normal once the actual printing initiates, I can
> print 10 pages in a row (in a single job) at normal speed, but it's very
> slow during the phase of submitting a new print job to the queue, and
> removing it from the queue, or submitting a "go-poweroff" command to the
> queue, or changing anything about printer state.
>
> I am guessing that maybe when the stream of data is mainly one way, it
> performs reasonably, while things like handshake with many message/response
> it probably goes very slow.
>
> Note that I have blacklisted usblp module in the host and noone is claiming
> the printer from the host.
>
> Dmesg since connecting the printer: (only 3 messages)
> [ 6870.292017] usb 1-3: new high speed USB device number 3 using ehci_hcd
> [ 6872.676028] usb 1-3: reset high speed USB device number 3 using ehci_hcd
> [ 6873.144032] usb 1-3: reset high speed USB device number 3 using ehci_hcd
>
> Qemu version is: Ubuntu Precise's qemu-kvm 1.0+noroms-0ubuntu6
>
> info usbhost:
> Bus 1, Addr 3, Port 3, Speed 480 Mb/s
> Class 00: USB device 04a9:10d2, iP4700 series
> Auto filters:
> Bus 1, Addr *, Port 5, ID *:*
> Bus 1, Addr *, Port 4, ID *:*
> Bus 1, Addr *, Port 3, ID *:*
> Bus 4, Addr *, Port 1, ID *:*
> Bus 3, Addr *, Port 2, ID *:*
> Bus 3, Addr *, Port 1, ID *:*
>
> info usb:
> Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet
> Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device
> Device 1.0, Port 2, Speed 1.5 Mb/s, Product USB Host Device
> Device 1.1, Port 3, Speed 480 Mb/s, Product iP4700 series
> Device 1.0, Port 4, Speed 1.5 Mb/s, Product USB Host Device
> Device 1.0, Port 5, Speed 1.5 Mb/s, Product USB Host Device
> Device 1.2, Port 6, Speed 12 Mb/s, Product QEMU USB Hub
> Device 1.0, Port 6.1, Speed 1.5 Mb/s, Product USB Host Device
>
> Note I am also using usb tablet... I might remove that if you say that an
> ehci-only setup is likely to go faster.
>
> Libvirt usb part:
> <qemu:commandline>
> <qemu:arg value='-device'/>
> <qemu:arg value='ich9-usb-ehci1,id=ehci,addr=1d.7,multifunction=on'/>
> <qemu:arg value='-device'/>
> <qemu:arg
> value='ich9-usb-uhci1,id=uhci-1,addr=1d.0,multifunction=on,masterbus=ehci.0,firstport=0'/>
>
> <qemu:arg value='-device'/>
> <qemu:arg
> value='ich9-usb-uhci2,id=uhci-2,addr=1d.1,multifunction=on,masterbus=ehci.0,firstport=2'/>
>
> <qemu:arg value='-device'/>
> <qemu:arg
> value='ich9-usb-uhci3,id=uhci-3,addr=1d.2,multifunction=on,masterbus=ehci.0,firstport=4'/>
>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=1,hostport=5'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=1,hostport=4'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=1,hostport=3'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=4,hostport=1'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=3,hostport=2'/>
> <qemu:arg value='-device'/>
> <qemu:arg value='usb-host,bus=ehci.0,hostbus=3,hostport=1'/>
> </qemu:commandline>
>
> generated command line:
> /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 2048 -smp
> 2,sockets=2,cores=1,threads=1 -name windows_cl3_v3.1 -uuid
> 0779e165-b11a-6d1c-fa92-f60ec5bdd9a7 -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/windows_cl3_v3.1.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc
> base=2012-04-02T20:37:15 -no-shutdown -boot order=c,menu=on -drive
> file=/dev/mapper/vg1-lv_cl3_v3.1,if=none,id=drive-ide0-0-0,format=raw,cache=writethrough,aio=native
> -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> file=/home/virtual_machines/ISO/ubuntu-11.10-desktop-amd64.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=writethrough,aio=native
> -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
> tap,fd=18,id=hostnet0 -device
> virtio-net-pci,event_idx=off,netdev=hostnet0,id=net0,mac=52:54:00:12:45:88,bus=pci.0,addr=0x3
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0
> -vnc 127.0.0.1:0 -vga cirrus -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -device
> ich9-usb-ehci1,id=ehci,addr=1d.7,multifunction=on -device
> ich9-usb-uhci1,id=uhci-1,addr=1d.0,multifunction=on,masterbus=ehci.0,firstport=0
> -device
> ich9-usb-uhci2,id=uhci-2,addr=1d.1,multifunction=on,masterbus=ehci.0,firstport=2
> -device
> ich9-usb-uhci3,id=uhci-3,addr=1d.2,multifunction=on,masterbus=ehci.0,firstport=4
> -device usb-host,bus=ehci.0,hostbus=1,hostport=5 -device
> usb-host,bus=ehci.0,hostbus=1,hostport=4 -device
> usb-host,bus=ehci.0,hostbus=1,hostport=3 -device
> usb-host,bus=ehci.0,hostbus=4,hostport=1 -device
> usb-host,bus=ehci.0,hostbus=3,hostport=2 -device
> usb-host,bus=ehci.0,hostbus=3,hostport=1
>
>
> Is this kind of performance to be expected with current status of ehci
> emulation in 1.0? Are there patches already I can backport to 1.0 (or use
> qemu development branch) to get higher speed?
>
> Thanks for any help
> R.
>

  reply	other threads:[~2012-04-03 13:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 12:26 [Qemu-devel] USB 2.0 printer passthrough very slow Reeted
2012-04-03 13:33 ` Erik Rull [this message]
2012-04-03 13:49   ` Reeted
2012-04-03 15:29     ` Erik Rull
2012-04-03 13:52 ` Reeted

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7AFC30.2060207@rdsoftware.de \
    --to=erik.rull@rdsoftware.de \
    --cc=qemu-devel@nongnu.org \
    --cc=reeted@shiftmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).