qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()

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...

 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....

  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-deve...

    Patch against current qemu-devel port:

	http://people.freebsd.org/~nox/qemu/qemu-deve...

[2] usbredir 0.3:

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

    Preliminary port:

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

Juergen Lock  writes:

> Hi!
>
>  I just prepared a preliminary update of the emulators/qemu-devel
>  port to 0.15.0[...]>     Patch against current qemu-devel port:
>
> 	http://people.freebsd.org/~nox/qemu/qemu-deve...Any plans to add option/port for SGABIOS or make it default?
It works fine here, screen seems to be limited to 25 lines
and I had to remove `-D' from /boot.config.

  $ qemu -nographic -drive file=/dev/ada1
  Could not open option rom 'sgabios.bin': No such file or directory

Test Rat  writes:

> Juergen Lock  writes:
>
>> Hi!
>>
>>  I just prepared a preliminary update of the emulators/qemu-devel
>>  port to 0.15.0
> [...]
>>     Patch against current qemu-devel port:
>>
>> 	http://people.freebsd.org/~nox/qemu/qemu-deve...
>
> Any plans to add option/port for SGABIOS or make it default?
> It works fine here, screen seems to be limited to 25 lines
> and I had to remove `-D' from /boot.config.
>
>   $ qemu -nographic -drive file=/dev/ada1
>   Could not open option rom 'sgabios.bin': No such file or directoryNevermind, after doing my homework it seems sgabios.bin is going to
be included into the distfile.

  http://lists.nongnu.org/archive/html/qemu-dev...

On Tue, Aug 16, 2011 at 03:52:21AM +0400, Test Rat wrote:
> Test Rat  writes:
> 
> > Juergen Lock  writes:
> >
> >> Hi!
> >>
> >>  I just prepared a preliminary update of the emulators/qemu-devel
> >>  port to 0.15.0
> > [...]
> >>     Patch against current qemu-devel port:
> >>
> >> 	http://people.freebsd.org/~nox/qemu/qemu-deve...
> >
> > Any plans to add option/port for SGABIOS or make it default?
> > It works fine here, screen seems to be limited to 25 lines
> > and I had to remove `-D' from /boot.config.
> >
> >   $ qemu -nographic -drive file=/dev/ada1
> >   Could not open option rom 'sgabios.bin': No such file or directory
> 
> Nevermind, after doing my homework it seems sgabios.bin is going to
> be included into the distfile.
> 
>   http://lists.nongnu.org/archive/html/qemu-dev...Well adding that to the build was easy enough, I made an svn snapshot
(r8) from:

	https://code.google.com/p/sgabios/
	svn checkout http://sgabios.googlecode.com/svn/trunk/ sgabios-read-only

and put it in my MASTER_SITES_LOCAL/nox, and also at:

	http://people.freebsd.org/~nox/qemu/sgabios-r...

for people to manually grab it and put it in /usr/ports/distfiles/qemu/0.15.0
until the mirrors have synced.

 I put the updated qemu-devel 0.15.0 port at the same place:

	http://people.freebsd.org/~nox/qemu/qemu-deve...
	http://people.freebsd.org/~nox/qemu/qemu-deve...

 HTH, :)
	Juergen

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 HCTry my patch first. EHCI needs to know device speed.

--HPS

=== 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)
 {

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...
> 
>  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....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

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 HCThat 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

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