Re: [Qemu-devel] usb-storage assertions

[Andrey Korolyov]

On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann <address@hidden> wrote:
>   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:

Whoops, sorry, should be 5.1/i386. On a 7.0 I observe same endless
loop as you do.

>
> [ ... ]
> address@hidden:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 0
> address@hidden:usb_ehci_queue_action q 0x7f94f7a98bb0: free
> [ ... ]
> address@hidden:usb_ehci_state periodic schedule INACTIVE
> address@hidden:usb_ehci_usbsts usbsts PSS 0
> address@hidden:usb_ehci_queue_action q 0x7f94f7a98cd0: free
> address@hidden:usb_ehci_queue_action q 0x7f94f7a98c40: free
> address@hidden:usb_ehci_queue_action q 0x7f94f749f040: free
> address@hidden:usb_ehci_queue_action q 0x7f94f749efb0: free
> address@hidden:usb_ehci_state async schedule INACTIVE
> address@hidden:usb_ehci_usbsts usbsts ASS 0
> address@hidden:usb_ehci_usbsts usbsts HALT 1
> address@hidden:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 2
> address@hidden:usb_ehci_reset === RESET ===
> address@hidden:usb_ehci_port_detach detach port #0, owner ehci
> address@hidden:usb_ehci_irq level 1, frindex 0x2958, sts
> 0x1004, mask 0x37
> address@hidden:usb_ehci_port_attach attach port #0, owner comp,
> device QEMU USB MSD
> address@hidden:usb_ehci_opreg_change ch mmio 0020 [USBCMD] =
> 80000 (old: 0)
> address@hidden:usb_ehci_opreg_read rd mmio 0024 [USBSTS] = 1000
> address@hidden: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
>