From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJhR6-0000DO-Qs for qemu-devel@nongnu.org; Wed, 11 Sep 2013 06:14:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJhR0-00063E-Qq for qemu-devel@nongnu.org; Wed, 11 Sep 2013 06:14:12 -0400 Received: from mail-bk0-f54.google.com ([209.85.214.54]:41719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJhR0-00062y-K6 for qemu-devel@nongnu.org; Wed, 11 Sep 2013 06:14:06 -0400 Received: by mail-bk0-f54.google.com with SMTP id mz12so3533210bkb.13 for ; Wed, 11 Sep 2013 03:14:05 -0700 (PDT) Message-ID: <52304270.1020507@m2r.biz> Date: Wed, 11 Sep 2013 12:14:08 +0200 From: Fabio Fantoni MIME-Version: 1.0 References: <1373624555-4403-1-git-send-email-fabio.fantoni@m2r.biz> <51DFE351.4000102@eu.citrix.com> <51E7E039.70606@suse.de> <51E7E0F4.5050006@redhat.com> <520B5C53.3060709@m2r.biz> In-Reply-To: <520B5C53.3060709@m2r.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com, George Dunlap , Ian.Jackson@eu.citrix.com, wei.lui2@citrix.com, qemu-devel@nongnu.org, Anthony Liguori , =?ISO-8859-1?Q?Andreas_F=E4rber?= Il 14/08/2013 12:30, Fabio Fantoni ha scritto: > Il 18/07/2013 14:35, Paolo Bonzini ha scritto: >> Il 18/07/2013 14:31, Andreas Färber ha scritto: >>>>> I'm just curious, why is this so complicated? Is this likely to be >>>>> fragile and break in the future? >>> As pointed out previously, the bus=pci.0 bit will break with different >>> PCI host bridges, such as the q35 machine existing today (-M q35 uses >>> pcie.0 instead and it has been discussed to make q35 the default at >>> some >>> point). I had thus suggested to use a variable for the bus name to >>> abstract it. For -M pc-i440fx-1.5 etc. pci.0 should continue to work. >> I think if we ever made a PCIe machine the default, it would be >> different from what today's q35. In particular it probably should >> include a default DMI-to-PCI bridge, so as to make the command line >> compatible with i440FX-based machines. >> >> Paolo > > FWIK q35 is not supported now on xen. > Anyone on this? > > Based on Anthony Liguori reply the usb2 hardcoded parameter should be > stable and will be supported in future: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01692.html > > There is also reply of Ian Jackson: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01702.html > > I had also posted v4 of patch: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01101.html > > > Reposted the tests results: > > Tested on linux domU (ubuntu 12.04 64 bit) with usb redirection: > - with usb1 and usb2 working and no problem found. > > - with usb3 linux sees the usb3 controller but usbredirection not > working (tested with qemu 1.3 of xen-unstable) > > Tested on windows 7 pro 64 bit domU with usb redirection: > > - with usb1 not working, windows sees the usb devices (flash mass > storage) with error (unable to start device, code 10); seems > windows bugs. > > - with usb2 working and no problem found. > > - with usb3 not working, windows sees the usb controller but > usbredirection is not working (tested with qemu 1.3 of xen-unstable) > > About usb3 seems that qemu does not support some functionalities for now. > > Qemu log on usb3 test: > xhci_cap_read: reg 2 unimplemented > xhci: unimplemented command 52 > xhci: ERDP out of bounds: 7e7d5000 > xhci: ER[7] at 0 len 0 > xhci: asserted controller error > xhci: ERDP out of bounds: 7eace000 > xhci: ER[6] at 0 len 0 > xhci: asserted controller error > ... > xhci: slot 1 has no device > xhci: error firing data transfer > > > > There wasn't any reply about this for one month. usb1 controller is > already supported by xen but it has some problems with latest windows. > usb2 works with both linux and windows but it needs this patch or a > similar one to add support on xen. usb3 can be removed for now if > someone think unimplemented functions are a problem. > Thanks for any reply. Ping From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu Date: Wed, 11 Sep 2013 12:14:08 +0200 Message-ID: <52304270.1020507@m2r.biz> References: <1373624555-4403-1-git-send-email-fabio.fantoni@m2r.biz> <51DFE351.4000102@eu.citrix.com> <51E7E039.70606@suse.de> <51E7E0F4.5050006@redhat.com> <520B5C53.3060709@m2r.biz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <520B5C53.3060709@m2r.biz> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Paolo Bonzini Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com, George Dunlap , Ian.Jackson@eu.citrix.com, wei.lui2@citrix.com, qemu-devel@nongnu.org, Anthony Liguori , =?ISO-8859-1?Q?Andreas_F=E4rber?= List-Id: xen-devel@lists.xenproject.org Il 14/08/2013 12:30, Fabio Fantoni ha scritto: > Il 18/07/2013 14:35, Paolo Bonzini ha scritto: >> Il 18/07/2013 14:31, Andreas Färber ha scritto: >>>>> I'm just curious, why is this so complicated? Is this likely to be >>>>> fragile and break in the future? >>> As pointed out previously, the bus=pci.0 bit will break with different >>> PCI host bridges, such as the q35 machine existing today (-M q35 uses >>> pcie.0 instead and it has been discussed to make q35 the default at >>> some >>> point). I had thus suggested to use a variable for the bus name to >>> abstract it. For -M pc-i440fx-1.5 etc. pci.0 should continue to work. >> I think if we ever made a PCIe machine the default, it would be >> different from what today's q35. In particular it probably should >> include a default DMI-to-PCI bridge, so as to make the command line >> compatible with i440FX-based machines. >> >> Paolo > > FWIK q35 is not supported now on xen. > Anyone on this? > > Based on Anthony Liguori reply the usb2 hardcoded parameter should be > stable and will be supported in future: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01692.html > > There is also reply of Ian Jackson: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01702.html > > I had also posted v4 of patch: > http://lists.xen.org/archives/html/xen-devel/2013-07/msg01101.html > > > Reposted the tests results: > > Tested on linux domU (ubuntu 12.04 64 bit) with usb redirection: > - with usb1 and usb2 working and no problem found. > > - with usb3 linux sees the usb3 controller but usbredirection not > working (tested with qemu 1.3 of xen-unstable) > > Tested on windows 7 pro 64 bit domU with usb redirection: > > - with usb1 not working, windows sees the usb devices (flash mass > storage) with error (unable to start device, code 10); seems > windows bugs. > > - with usb2 working and no problem found. > > - with usb3 not working, windows sees the usb controller but > usbredirection is not working (tested with qemu 1.3 of xen-unstable) > > About usb3 seems that qemu does not support some functionalities for now. > > Qemu log on usb3 test: > xhci_cap_read: reg 2 unimplemented > xhci: unimplemented command 52 > xhci: ERDP out of bounds: 7e7d5000 > xhci: ER[7] at 0 len 0 > xhci: asserted controller error > xhci: ERDP out of bounds: 7eace000 > xhci: ER[6] at 0 len 0 > xhci: asserted controller error > ... > xhci: slot 1 has no device > xhci: error firing data transfer > > > > There wasn't any reply about this for one month. usb1 controller is > already supported by xen but it has some problems with latest windows. > usb2 works with both linux and windows but it needs this patch or a > similar one to add support on xen. usb3 can be removed for now if > someone think unimplemented functions are a problem. > Thanks for any reply. Ping