[Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Juergen Lock]

Hi!

 I just prepared a preliminary update of the emulators/qemu-devel
port to 0.15.0 [1], and among other things it now also has a
usb network redirection feature using usbredir [2], which uses
libusb 1.0 and a function that is missing in our version,
libusb_get_device_speed().  I added a stub to the code that
always returns LIBUSB_SPEED_UNKNOWN
(files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
question for Hans (I guess), would there be an easy way to make a
`proper' implementation?

 If anyone wants to help me test qemu 0.15.0, thanx!

 I also updated the net.c and net.h udp patches for gns3 for this qemu
version: (the other gns3 patchfiles for qemu 0.14 still apply)

	http://people.freebsd.org/~nox/qemu/qemu-0.15.0-gns3-patches/

 I added this note to the qemu-devel pkg-message about the usb
redirection [1]:

------------snip------
- If you want to test the new (in 0.15.0) usb network redirection (USBREDIR
  option) see this thread by Hans de Goede <hdegoede <at> redhat.com>:

        http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183

  Quote:

  Example usage:

  1) Start usbredirserver for a usb device:
  sudo usbredirserver 045e:0772
  2) Start qemu with usb2 support + a chardev talking to usbredirserver +
     a usb-redir device using this chardev:
  qemu ... \
    -readconfig docs/ich9-ehci-uhci.cfg \
    -chardev socket,id=usbredirchardev,host=localhost,port=4000 \
    -device usb-redir,chardev=usbredirchardev,id=usbredirdev

  [you would replace docs/ich9-ehci-uhci.cfg with e.g.
  /usr/local/share/doc/qemu/docs/ich9-ehci-uhci.cfg, but turns out
  ehci seems broken for me here with FreeBSD guests at least, I get:

        FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet
processing error - resetting ehci HC

        Assertion failed: (0), function ehci_advance_state, file /data/ports/emulators/qemu-devel/work/qemu-0.15.0/hw/usb-ehci.c, line 2045.

  Starting the same without ehci (-readconfig) works, tho usbredirserver
  crashes when qemu exits.]
------------snip------

 Thanx! :)
	Juergen


[1] Changelog:

	http://wiki.qemu.org/ChangeLog/0.15

    Preliminary port:

	http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.shar

    Patch against current qemu-devel port:

	http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.patch

[2] usbredir 0.3:

	http://cgit.freedesktop.org/~jwrdegoede/usbredir/

    Preliminary port:

	http://people.freebsd.org/~nox/qemu/usbredir.shar

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Hans Petter Selasky]

[-- Attachment #1: Type: Text/Plain, Size: 945 bytes --]

On Monday 15 August 2011 22:26:56 Juergen Lock wrote:
> Hi!
> 
>  I just prepared a preliminary update of the emulators/qemu-devel
> port to 0.15.0 [1], and among other things it now also has a
> usb network redirection feature using usbredir [2], which uses
> libusb 1.0 and a function that is missing in our version,
> libusb_get_device_speed().  I added a stub to the code that
> always returns LIBUSB_SPEED_UNKNOWN
> (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
> question for Hans (I guess), would there be an easy way to make a
> `proper' implementation?
> 
>  If anyone wants to help me test qemu 0.15.0, thanx!

Please try the attached patch to libusb in /usr/src/lib/libusb .

You only need to rebuild libusb: make all install clean

>         FETCHENTRY: entry at 22C5484 is of type 2 which is not supported
> yet processing error - resetting ehci HC

Try my patch first. EHCI needs to know device speed.

--HPS

[-- Attachment #2: libusb_speed.txt --]
[-- Type: text/plain, Size: 1659 bytes --]

=== libusb.h
==================================================================
--- libusb.h	(revision 224768)
+++ libusb.h	(local)
@@ -151,6 +151,14 @@
 	LIBUSB_ERROR_OTHER = -99,
 };
 
+enum libusb_speed {
+	LIBUSB_SPEED_UNKNOWN = 0,
+	LIBUSB_SPEED_LOW = 1,
+	LIBUSB_SPEED_FULL = 2,
+	LIBUSB_SPEED_HIGH = 3,
+	LIBUSB_SPEED_SUPER = 4,
+};
+
 enum libusb_transfer_status {
 	LIBUSB_TRANSFER_COMPLETED,
 	LIBUSB_TRANSFER_ERROR,
@@ -304,6 +312,7 @@
 void	libusb_free_device_list(libusb_device ** list, int unref_devices);
 uint8_t	libusb_get_bus_number(libusb_device * dev);
 uint8_t	libusb_get_device_address(libusb_device * dev);
+enum libusb_speed libusb_get_device_speed(libusb_device * dev);
 int	libusb_clear_halt(libusb_device_handle *devh, uint8_t endpoint);
 int	libusb_get_max_packet_size(libusb_device * dev, uint8_t endpoint);
 libusb_device *libusb_ref_device(libusb_device * dev);
=== libusb10.c
==================================================================
--- libusb10.c	(revision 224768)
+++ libusb10.c	(local)
@@ -272,6 +272,27 @@
 	return (libusb20_dev_get_address(dev->os_priv));
 }
 
+enum libusb_speed
+libusb_get_device_speed(libusb_device *dev)
+{
+	if (dev == NULL)
+		return (0);		/* should not happen */
+
+	switch (libusb20_dev_get_speed(dev->os_priv)) {
+	case LIBUSB20_SPEED_LOW:
+		return (LIBUSB_SPEED_LOW);
+	case LIBUSB20_SPEED_FULL:
+		return (LIBUSB_SPEED_FULL);
+	case LIBUSB20_SPEED_HIGH:
+		return (LIBUSB_SPEED_HIGH);
+	case LIBUSB20_SPEED_SUPER:
+		return (LIBUSB_SPEED_SUPER);
+	default:
+		break;
+	}
+	return (LIBUSB_SPEED_UNKNOWN);
+}
+
 int
 libusb_get_max_packet_size(libusb_device *dev, uint8_t endpoint)
 {

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Hans Petter Selasky]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Monday 15 August 2011 22:26:56 Juergen Lock wrote:
> Hi!
> 
>  I just prepared a preliminary update of the emulators/qemu-devel
> port to 0.15.0 [1], and among other things it now also has a
> usb network redirection feature using usbredir [2], which uses
> libusb 1.0 and a function that is missing in our version,
> libusb_get_device_speed().  I added a stub to the code that
> always returns LIBUSB_SPEED_UNKNOWN
> (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
> question for Hans (I guess), would there be an easy way to make a
> `proper' implementation?
> 
>  If anyone wants to help me test qemu 0.15.0, thanx!

Please try the attached patch to libusb in /usr/src/lib/libusb .

You only need to rebuild libusb: make all install clean

>         FETCHENTRY: entry at 22C5484 is of type 2 which is not supported
> yet processing error - resetting ehci HC

Try my patch first. EHCI needs to know device speed.

--HPS

[-- Attachment #2: libusb_speed.txt --]
[-- Type: text/plain, Size: 1659 bytes --]

=== libusb.h
==================================================================
--- libusb.h	(revision 224768)
+++ libusb.h	(local)
@@ -151,6 +151,14 @@
 	LIBUSB_ERROR_OTHER = -99,
 };
 
+enum libusb_speed {
+	LIBUSB_SPEED_UNKNOWN = 0,
+	LIBUSB_SPEED_LOW = 1,
+	LIBUSB_SPEED_FULL = 2,
+	LIBUSB_SPEED_HIGH = 3,
+	LIBUSB_SPEED_SUPER = 4,
+};
+
 enum libusb_transfer_status {
 	LIBUSB_TRANSFER_COMPLETED,
 	LIBUSB_TRANSFER_ERROR,
@@ -304,6 +312,7 @@
 void	libusb_free_device_list(libusb_device ** list, int unref_devices);
 uint8_t	libusb_get_bus_number(libusb_device * dev);
 uint8_t	libusb_get_device_address(libusb_device * dev);
+enum libusb_speed libusb_get_device_speed(libusb_device * dev);
 int	libusb_clear_halt(libusb_device_handle *devh, uint8_t endpoint);
 int	libusb_get_max_packet_size(libusb_device * dev, uint8_t endpoint);
 libusb_device *libusb_ref_device(libusb_device * dev);
=== libusb10.c
==================================================================
--- libusb10.c	(revision 224768)
+++ libusb10.c	(local)
@@ -272,6 +272,27 @@
 	return (libusb20_dev_get_address(dev->os_priv));
 }
 
+enum libusb_speed
+libusb_get_device_speed(libusb_device *dev)
+{
+	if (dev == NULL)
+		return (0);		/* should not happen */
+
+	switch (libusb20_dev_get_speed(dev->os_priv)) {
+	case LIBUSB20_SPEED_LOW:
+		return (LIBUSB_SPEED_LOW);
+	case LIBUSB20_SPEED_FULL:
+		return (LIBUSB_SPEED_FULL);
+	case LIBUSB20_SPEED_HIGH:
+		return (LIBUSB_SPEED_HIGH);
+	case LIBUSB20_SPEED_SUPER:
+		return (LIBUSB_SPEED_SUPER);
+	default:
+		break;
+	}
+	return (LIBUSB_SPEED_UNKNOWN);
+}
+
 int
 libusb_get_max_packet_size(libusb_device *dev, uint8_t endpoint)
 {

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Hans Petter Selasky]

On Monday 15 August 2011 22:26:56 Juergen Lock wrote:
> Hi!
> 
>  I just prepared a preliminary update of the emulators/qemu-devel
> port to 0.15.0 [1], and among other things it now also has a
> usb network redirection feature using usbredir [2], which uses
> libusb 1.0 and a function that is missing in our version,
> libusb_get_device_speed().  I added a stub to the code that
> always returns LIBUSB_SPEED_UNKNOWN
> (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
> question for Hans (I guess), would there be an easy way to make a
> `proper' implementation?
> 
>  If anyone wants to help me test qemu 0.15.0, thanx!
> 
>  I also updated the net.c and net.h udp patches for gns3 for this qemu
> version: (the other gns3 patchfiles for qemu 0.14 still apply)
> 
> 	http://people.freebsd.org/~nox/qemu/qemu-0.15.0-gns3-patches/
> 
>  I added this note to the qemu-devel pkg-message about the usb
> redirection [1]:
> 
> ------------snip------
> - If you want to test the new (in 0.15.0) usb network redirection (USBREDIR
>   option) see this thread by Hans de Goede <hdegoede <at> redhat.com>:
> 
>        
> http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183

Hi,

It is also crashing here:

usbredirserver 0c76:1607
usbredirparser info: Peer version: qemu usb-redir guest 0.15.0
Bus error (core dumped)

qemu -cdrom xxx.iso -readconfig /usr/local/share/doc/qemu/docs/ich9-ehci-
uhci.cfg -chardev socket,id=usbredirchardev,host=localhost,port=4000 -device 
usb-redir,chardev=usbredirchardev,id=usbredirdev
*** EHCI support is under development ***
FETCHENTRY: entry at 3DBFD04 is of type 2 which is not supported yet
processing error - resetting ehci HC
Assertion failed: (0), function ehci_advance_state, file 
/usr/ports/emulators/qemu-devel/work/qemu-0.15.0/hw/usb-ehci.c, line 2045.
Abort (core dumped)


Maybe Hans de Goede should do some testing with FreeBSD-current ?

I just submitted the patch for FreeBSD-current that implements 
libusb_get_device_speed().

--HPS

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Juergen Lock]

On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote:
> On Monday 15 August 2011 22:26:56 Juergen Lock wrote:
> > Hi!
> > 
> >  I just prepared a preliminary update of the emulators/qemu-devel
> > port to 0.15.0 [1], and among other things it now also has a
> > usb network redirection feature using usbredir [2], which uses
> > libusb 1.0 and a function that is missing in our version,
> > libusb_get_device_speed().  I added a stub to the code that
> > always returns LIBUSB_SPEED_UNKNOWN
> > (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
> > question for Hans (I guess), would there be an easy way to make a
> > `proper' implementation?
> > 
> >  If anyone wants to help me test qemu 0.15.0, thanx!
> 
> Please try the attached patch to libusb in /usr/src/lib/libusb .
> 
> You only need to rebuild libusb: make all install clean
> 
> >         FETCHENTRY: entry at 22C5484 is of type 2 which is not supported
> > yet processing error - resetting ehci HC
> 
> Try my patch first. EHCI needs to know device speed.

Thanx, tho it turns out:

a) the FETCHENTRY:.. crash also happens without any device redirection
   with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig
   docs/ich9-ehci-uhci.cfg), and

b) if I test this with your patch (working libusb_get_device_speed()
   that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting
   an usb 2.0 device with ehci enabled using usbredir then qemu
   complains like:

	qemu: Warning: speed mismatch trying to attach usb device USB Redirectio
n Device to bus usb.0

   and ignores the redirected device.  So for now I have added a
   #define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary
   usbredir FreeBSD port,

	http://people.freebsd.org/~nox/qemu/usbredir.shar

   so that usbredirhost_open() now always works with:

	device_connect.speed = usb_redir_speed_unknown;

 Question: do people also see this problem on Linux?  This post has
an usage example:

	http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183

 Or is the problem just that with the example usage,

	sudo usbredirserver 045e:0772
	...
	qemu ... \
	    -readconfig docs/ich9-ehci-uhci.cfg \
	    -chardev socket,id=usbredirchardev,host=localhost,port=4000 \
	    -device usb-redir,chardev=usbredirchardev,id=usbredirdev

qemu 0.15.0 tries to attach the redirected usb 2.0 device to the
uhci bus instead of to the ehci one and if yes, how can I fix that?

 Thanx! :)
	Juergen

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Juergen Lock]

On Tue, Aug 16, 2011 at 09:54:23PM +0200, Juergen Lock wrote:
> On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote:
> > On Monday 15 August 2011 22:26:56 Juergen Lock wrote:
> > > Hi!
> > > 
> > >  I just prepared a preliminary update of the emulators/qemu-devel
> > > port to 0.15.0 [1], and among other things it now also has a
> > > usb network redirection feature using usbredir [2], which uses
> > > libusb 1.0 and a function that is missing in our version,
> > > libusb_get_device_speed().  I added a stub to the code that
> > > always returns LIBUSB_SPEED_UNKNOWN
> > > (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]),
> > > question for Hans (I guess), would there be an easy way to make a
> > > `proper' implementation?
> > > 
> > >  If anyone wants to help me test qemu 0.15.0, thanx!
> > 
> > Please try the attached patch to libusb in /usr/src/lib/libusb .
> > 
> > You only need to rebuild libusb: make all install clean
> > 
> > >         FETCHENTRY: entry at 22C5484 is of type 2 which is not supported
> > > yet processing error - resetting ehci HC
> > 
> > Try my patch first. EHCI needs to know device speed.
> 
> Thanx, tho it turns out:
> 
> a) the FETCHENTRY:.. crash also happens without any device redirection
>    with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig
>    docs/ich9-ehci-uhci.cfg), and
> 
> b) if I test this with your patch (working libusb_get_device_speed()
>    that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting
>    an usb 2.0 device with ehci enabled using usbredir then qemu
>    complains like:
> 
> 	qemu: Warning: speed mismatch trying to attach usb device USB Redirectio
> n Device to bus usb.0
> 
>    and ignores the redirected device.  So for now I have added a
>    #define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary
>    usbredir FreeBSD port,
> 
> 	http://people.freebsd.org/~nox/qemu/usbredir.shar
> 
>    so that usbredirhost_open() now always works with:
> 
> 	device_connect.speed = usb_redir_speed_unknown;
> 
>  Question: do people also see this problem on Linux?  This post has
> an usage example:
> 
> 	http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183
> 
>  Or is the problem just that with the example usage,
> 
> 	sudo usbredirserver 045e:0772
> 	...
> 	qemu ... \
> 	    -readconfig docs/ich9-ehci-uhci.cfg \
> 	    -chardev socket,id=usbredirchardev,host=localhost,port=4000 \
> 	    -device usb-redir,chardev=usbredirchardev,id=usbredirdev
> 
> qemu 0.15.0 tries to attach the redirected usb 2.0 device to the
> uhci bus instead of to the ehci one and if yes, how can I fix that?

Nevermind, I didn't actually put the -readconfig parameter first. :(
(It didn't occur to me that the order would matter...)

 But now I found that:

a) seabios hangs at boot when I redirect an usb 2.0 flashkey with
   ehci enabled (at least with -cdrom), and

b) with ehci disabled I still get the speed mismatch warning and
   the device is ignored.  Maybe the speed mismatch check should
   be relaxed if there isn't a bus as fast as the device, and the
   device be attached to the fastest available bus instead?  (i.e.
   also the same is likely to happen with usb 3.0 devices?)

 Thanx,
	Juergen  (who will leave the FreeBSD usbredir port using
usb_redir_speed_unknown for now I guess...)

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Gerd Hoffmann]

   Hi,

> a) the FETCHENTRY:.. crash also happens without any device redirection
>     with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig
>     docs/ich9-ehci-uhci.cfg), and

That will likely happen with a freebsd guest on a linux host too, looks 
like freebsd asks ehci to do something which isn't (fully) implemented 
in the emulation code.  Will have a look.

> 	qemu ... \
> 	    -readconfig docs/ich9-ehci-uhci.cfg \
> 	    -chardev socket,id=usbredirchardev,host=localhost,port=4000 \
> 	    -device usb-redir,chardev=usbredirchardev,id=usbredirdev
>
> qemu 0.15.0 tries to attach the redirected usb 2.0 device to the
> uhci bus instead of to the ehci one and if yes, how can I fix that?

-device usb-redir,bus=ehci.0,...

HTH,
   Gerd

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Gerd Hoffmann]

   Hi,

>    [you would replace docs/ich9-ehci-uhci.cfg with e.g.
>    /usr/local/share/doc/qemu/docs/ich9-ehci-uhci.cfg, but turns out
>    ehci seems broken for me here with FreeBSD guests at least, I get:
>
>          FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet
> processing error - resetting ehci HC

That is a transfer descriptor for isochronous split transfers (siTD). 
Split transfers are used to support 1.1 devices behind 2.0 hubs.  There 
is no USB 2.0 Hub emulation in qemu and also no split transfer emulation 
in EHCI, thats why the failure.

/me wonders what FreeBSD tries to do here?  This triggers even without a 
single device connected and I can't think of a reason to use a siTD in 
that case ...

Nevertheless qemu shouldn't fail like that.

cheers,
   Gerd

Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

[Gerd Hoffmann]

   Hi,

> /me wonders what FreeBSD tries to do here? This triggers even without a
> single device connected and I can't think of a reason to use a siTD in
> that case ...

Ah, the siTD simply isn't active so we can just skip it.
That is easy to do ;)

cheers,
   Gerd