Re: Bug in usbdevices option handling when BusID=8

[George Dunlap <george.dunlap@eu.citrix.com>]

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 <Ian.Campbell@citrix.com> 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