Re: [Qemu-devel] usb-storage assertions

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > ok.  Had no trouble with freebsd, will go fetch netbsd images.  What
> > arch is this?  i386?  x86_64?
> 
> i386 7.0 for the reference, but I`m sure that this wouldn`t matter in
> any way.

7.0 trace:

[ ... ]
12417@1453119296.506252:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 0
12417@1453119296.506284:usb_ehci_queue_action q 0x7f94f7a98bb0: free
[ ... ]
12417@1453119296.507336:usb_ehci_state periodic schedule INACTIVE
12417@1453119296.507340:usb_ehci_usbsts usbsts PSS 0
12417@1453119296.507344:usb_ehci_queue_action q 0x7f94f7a98cd0: free
12417@1453119296.507349:usb_ehci_queue_action q 0x7f94f7a98c40: free
12417@1453119296.507353:usb_ehci_queue_action q 0x7f94f749f040: free
12417@1453119296.507357:usb_ehci_queue_action q 0x7f94f749efb0: free
12417@1453119296.507361:usb_ehci_state async schedule INACTIVE
12417@1453119296.507365:usb_ehci_usbsts usbsts ASS 0
12417@1453119296.507369:usb_ehci_usbsts usbsts HALT 1
12417@1453119296.507402:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 2
12417@1453119296.507413:usb_ehci_reset === RESET ===
12417@1453119296.507418:usb_ehci_port_detach detach port #0, owner ehci
12417@1453119296.507423:usb_ehci_irq level 1, frindex 0x2958, sts
0x1004, mask 0x37
12417@1453119296.507435:usb_ehci_port_attach attach port #0, owner comp,
device QEMU USB MSD
12417@1453119296.507444:usb_ehci_opreg_change ch mmio 0020 [USBCMD] =
80000 (old: 0)
12417@1453119296.507466:usb_ehci_opreg_read rd mmio 0024 [USBSTS] = 1000
12417@1453119296.507510:usb_ehci_opreg_read rd mmio 0024 [USBSTS] = 1000
[ ... ]

So, to shutdown ehci netbsd clears the cmd register, then sets the reset
bit in the cmd register.  Fine.  

Then it goes read the status register, in a loop, forever.  No idea why,
and I also can't spot then place in the source code.  Hmm ...

>  Just to mention - ancient 2.6, like 2.6.18, are actually
> doing things quite faster using same frontend+backend combination, may
> be due to lack of proper timeout checks... Actually there is a very
> small chance that the real performance regression was introduced
> during further development, so I instead believe in improper
> interaction of a newer guest EHCI driver and qemu frontend.

Could also be older ehci guest drivers took a shortcut which turned out
to not be correct and not working reliable ...

> Please let
> me know if any countable measurements like fio could be a matter of
> interest - I don`t think that many people are concerned about USB/USB2
> frontend performance at all, since they are bringing in a ton of
> unwelcomed wakeups and the one thing which could be a matter of
> concern in that case is an emulated xHCI, IMHO.

Yes, xhci is clearly the best choice when it comes to performance.

Reasons to use ehci instead basically boils down to (a) lacking/broken
guest drivers (old windows versions, also early linux xhci driver
versions had endian issues, firmware needs xhci support too to boot from
usb) and (b) historical (ehci emulation was there first, so support in
the management stack tends to be better for that, also people are used
to it).

cheers,
  Gerd