From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Bug in usbdevices option handling when BusID=8 Date: Fri, 13 Dec 2013 11:04:01 +0000 Message-ID: <52AAE9A1.9000200@eu.citrix.com> References: <51FE362A.3000300@bobich.net> <1375687784.15681.84.camel@dagon.hellion.org.uk> <51FFFAE8.1000206@bobich.net> <20131212170149.GA5318@perard.uk.xensource.com> <52A9F265.7080406@eu.citrix.com> <20131212193201.GW10855@perard.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131212193201.GW10855@perard.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Anthony PERARD Cc: Gordan Bobic , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 12/12/2013 07:32 PM, Anthony PERARD wrote: > On Thu, Dec 12, 2013 at 05:29:09PM +0000, George Dunlap wrote: >> On 12/12/2013 05:01 PM, Anthony PERARD wrote: >>> On Mon, Aug 05, 2013 at 08:20:08PM +0100, Gordan Bobic wrote: >>>> On 08/05/2013 02:22 PM, George Dunlap wrote: >>>>> On Mon, Aug 5, 2013 at 8:29 AM, Ian Campbell wrote: >>>>>> On Sun, 2013-08-04 at 12:08 +0100, Gordan Bobic wrote: >>>>>>> At a glance, this looks like something buggy happens when BusID=8. It >>>>>>> sees that the device is host:008.002, but then goes and tries to open >>>>>>> /dev/bus/usb/000/002 instead of /dev/bus/usb/008/002. >>>>>> Smells like a bitmask gone wrong somewhere, or something like that. >>>>>> >>>>>> xl/libxl doesn't really do much with the string which you passed in so >>>>>> it should be going straight to qemu unmodified. You ought to be able to >>>>>> see this in the logs I think. >>>>> Or using ps -ax -- what does that show the command-line to be? >>>> It looks like a qemu-traditional (qemu-dm) issue: >>>> >>>> # grep usb /var/log/xen/qemu-dm-edi.log >>>> husb: open device 0.2 >>>> /dev/bus/usb/000/002: No such file or directory >>>> >>>> # ps auxw | grep qemu >>>> root 8364 4.4 0.0 239132 8880 ? SLsl 20:16 0:07 >>>> /usr/lib/xen/bin/qemu-dm -d 1 -domain-name edi -vnc 127.0.0.1:0 -vncunused >>>> -k en-gb -serial pty -videoram 8 -std-vga -boot c -usb -usbdevice >>>> host:008.002 -acpi -vcpus 8 -vcpu_avail 0xff -net >>>> nic,vlan=0,macaddr=00:16:3e:4e:c5:0c,model=e1000 -net >>>> tap,vlan=0,ifname=vif1.0-emu,bridge=br0,script=no,downscript=no -M xenfv >>> I've just look into this bug. The problem is the way the convertion of >>> the string is done. And it is just a: >>> strtoul(devname, NULL, 0); >>> >>> Here, strtoul while try to guess the base of the string, and a string >>> that begin by zero while be interpreted to be base 8, or octal. The >>> character '8' those not belong to this base, so the conversion stop >>> before '8' and the value return is 0. >>> >>> We could force the base to be 10, but that mean that anyone who whould >>> have something like "host:0x4.0x2" while have a configuration that those >>> not work anymore. >>> >>> In your case, you can have: >>> usbdevice="host:8.2" which will fix the issue. >> What does qemu-xen do? > QEMU does exactly the same. > >> I'm not sure "host:0x04.0x2" is a supported format. > I'm not actually sure which format is supported. Here is a list of > format I could find. > - man qemu > host:bus.addr > > That the only place I find this format. Most webpage I could find use > host:vendor_id:product_id format. Even xen documentation use it (before > to send the user to man qemu): > > - man xl.cfg > Host devices can also be passed through in this way, by specifying > host:USBID, where USBID is of the form xxxx:yyyy. The USBID can > typically be found by using lsusb or usb-devices. > >> You can see that "00x" >> is used in Linux in /dev; it's also used in lsusb, for instance, and I think >> a number of the other tools. I think it would make much more sense to match >> the format of these other tools, than to allow people to specify it in hex >> (using "0x") and have people trip over issues like this. > Yes, I see the point. > > Well, with whatever supported format I could come up with, I suppose we > can handle something like host:009.003 as 9.3 with no issue on > qemu-traditional. I don't know if we can do the same for QEMU. I think qemu-traditional should do what qemu-xen does. (I was confused by Gordan saying it was a qemu-traditional issue.) So for now I think we should just document this. It might be worth submitting a patch to qemu upstream to see what people think of it and then backporting it if it's accepted; but obviously that's low priority at this point. -George