[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5] libxl: usb2 and usb3 controller support for upstream qemu



Il 18/09/2013 09:44, Fabio Fantoni ha scritto:
Il 17/09/2013 20:04, Fabio Fantoni ha scritto:
About bus and multifunction should be correct based on reply of one qemu developer time ago if I remember good.
I also require advice of other improve for usb2 parameters if possible without reply.
On my latest tests:
- on Ubuntu 12.04 domU usb1, usb2 and usb3 are working
- on windows 7 64 bit domU usb 2 and usb3 are working, usb1 not (seem windows problem, probably also other windows versions have this problem)
About id seems needed for usb redirection, next test I'll try to remove the id to check if automatic search and use the usb controller.

Sorry for my bad english.


Sorry, I forgot the cc.


2013/9/17 Anthony PERARD <anthony.perard@xxxxxxxxxx>
On Fri, Sep 13, 2013 at 04:25:37PM +0200, Fabio Fantoni wrote:
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 43c3bec..e0123b7 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -511,7 +511,30 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      __func__);
>                  return NULL;
>              }
> -            flexarray_append(dm_args, "-usb");
> +
> +            switch (b_info->u.hvm.usbversion) {
> +            case 1:
> +                flexarray_vappend(dm_args,
> +                    "-device", "piix3-usb-uhci,id=usb", NULL);
> +                break;
> +            case 2:
> +                flexarray_append_pair(dm_args, "-device",
> +                    "ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x1d.0x7");
> +                for (i = 1; i < 4; i++)
> +                    flexarray_append_pair(dm_args, "-device",
> +                        GCSPRINTF("ich9-usb-uhci%d,masterbus=usb.0,"
> +                        "firstport=%d,bus=pci.0%s,addr=0x1d.%#x", i,
> +                        2*(i-1), i == 1 ?",multifunction=on" : "", i-1));
> +                break;
> +            case 3:
> +                flexarray_vappend(dm_args,
> +                    "-device", "nec-usb-xhci,id=usb", NULL);
> +                break;
> +            default:
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                    "usbversion parameter is invalid must be between 1 and 3");
> +                return NULL;
> +            }
>              if (b_info->u.hvm.usbdevice) {
>                  flexarray_vappend(dm_args,
>                                    "-usbdevice", b_info->u.hvm.usbdevice, NULL);

I've took a look at the QEMU command line, and especially the usb2 case.
I think the bus=pci.0 is not needed, QEMU does not complain and the usb
controller is visible in the guest.

On my new test works also without bus=pci.0, I'll remove it on next patch version.


About the id, I think it would be better to name the different version
with different ids, they could be uhci, ehci and xhci as I saw in few
example, or it could be usb1, usb2, usb3. So when those id are used
later, they will carry which usb version there are providing, without
the need to know how the guest have been configured.

On my new test usbredirection works also without adding the usb controller id, so it is possible to change it but I think is unuseful change it based on different usb version.


About the multifunction=on, do you know why it's only on applied to one
of the ich9-usb-uhci devices (in the for loop)? Would it change
something to applied to all of them?

On my new test I added multifunction=on on all devices and all is working. I see on qemu docs/ich9-ehci-uhci.cfg and all devices have multifunction enabled, on next patch version I'll put it on all devices.


Otherwise, there is some docs in the qemu.git tree to make sense of
this, and especially docs/usb2.txt.

--
Anthony PERARD



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.