Bug in usbdevices option handling when BusID=8

Bug in usbdevices option handling when BusID=8

[Gordan Bobic]

Configuration: Xen 4.3.0, xl

I have been trying to pass USB mouse and keyboard through do a domU 
using usbdevices = [] option. The success/failure seems to be related to 
the bus.device option.

Specifically, in quemu log:

husb: open device 0.2
/dev/bus/usb/000/002: No such file or directory
Warning: could not add USB device host:008.002
husb: open device 6.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 6.2

In domU config:
usbdevice = [ 'host:008.002', 'host:006.002' ]

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.

If I change the port where the device is connected and it gets a 
different ID, and I change the config to:

usbdevice = [ 'host:003.002', 'host:006.002' ]

the log then says:

husb: open device 3.2
husb: config #1 need -1
husb: 1 interfaces claimed for configuration 1
husb: grabbed usb device 3.2
husb: open device 6.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 6.2

and both devices are availble in domU.

Bug?

Gordan

Re: Bug in usbdevices option handling when BusID=8

[Gordan Bobic]

On 08/04/2013 12:08 PM, Gordan Bobic wrote:
> Configuration: Xen 4.3.0, xl
>
> I have been trying to pass USB mouse and keyboard through do a domU
> using usbdevices = [] option. The success/failure seems to be related to
> the bus.device option.
>
> Specifically, in quemu log:
>
> husb: open device 0.2
> /dev/bus/usb/000/002: No such file or directory
> Warning: could not add USB device host:008.002
> husb: open device 6.2
> husb: config #1 need -1
> husb: 2 interfaces claimed for configuration 1
> husb: grabbed usb device 6.2
>
> In domU config:
> usbdevice = [ 'host:008.002', 'host:006.002' ]
>
> 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.
>
> If I change the port where the device is connected and it gets a
> different ID, and I change the config to:
>
> usbdevice = [ 'host:003.002', 'host:006.002' ]
>
> the log then says:
>
> husb: open device 3.2
> husb: config #1 need -1
> husb: 1 interfaces claimed for configuration 1
> husb: grabbed usb device 3.2
> husb: open device 6.2
> husb: config #1 need -1
> husb: 2 interfaces claimed for configuration 1
> husb: grabbed usb device 6.2
>
> and both devices are availble in domU.
>
> Bug?

There also appears to be a further bug in handling of usb devices. When 
I change the device to not be on bus 8, I get this for some devices:

husb: open device 3.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 3.2
husb: open device 4.2
husb: config #1 need -1
husb: 2 interfaces claimed for configuration 1
husb: grabbed usb device 4.2
usb_linux_update_endp_table: Invalid or incomplete multibyte or wide 
character

The device seems to get added (stops working in dom0), but then doesn't 
appear to work in domU, presumably due to the error line above.

Gordan

Re: Bug in usbdevices option handling when BusID=8

[Ian Campbell]

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. So it seems like there is a bug on the
qemu side. Which DM were you using?

Ian.

Re: Bug in usbdevices option handling when BusID=8

[George Dunlap]

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?

 -George

Re: Bug in usbdevices option handling when BusID=8

[Gordan Bobic]

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

Gordan

Re: Bug in usbdevices option handling when BusID=8

[George Dunlap]

On Mon, Aug 5, 2013 at 8:20 PM, Gordan Bobic <gordan@bobich.net> 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

Could you test qemu-xen with configuration, to test to see if it
works?  If it doesn't we probably need to report this upstream --
otherwise it's just a matter of fixing it in our tree.

 -George

Re: Bug in usbdevices option handling when BusID=8

[Gordan Bobic]

 On Tue, 6 Aug 2013 10:24:09 +0100, George Dunlap 
 <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Aug 5, 2013 at 8:20 PM, Gordan Bobic <gordan@bobich.net> 
> 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
>
> Could you test qemu-xen with configuration, to test to see if it
> works?  If it doesn't we probably need to report this upstream --
> otherwise it's just a matter of fixing it in our tree.

 I'll have to rebuild my packages to test that - my build only includes
 qemu-dm.

 Gordan

Re: Bug in usbdevices option handling when BusID=8

[George Dunlap]

create ^
title it qemu-traditional mis-parses host bus 8 as 0
thanks

On Mon, Aug 5, 2013 at 8:20 PM, Gordan Bobic <gordan@bobich.net> 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
>
> Gordan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Processed: Re: Bug in usbdevices option handling when BusID=8

[xen]

Processing commands for xen@bugs.xenproject.org:

> create ^
Created new bug #15 rooted at `<51FFFAE8.1000206@bobich.net>'
Title: `Re: [Xen-devel] Bug in usbdevices option handling when BusID=8'
> title it qemu-traditional mis-parses host bus 8 as 0
Set title for #15 to `qemu-traditional mis-parses host bus 8 as 0'
> thanks
Finished processing.

Modified/created Bugs:
 - 15: http://bugs.xenproject.org/xen/bug/15 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

Re: Bug in usbdevices option handling when BusID=8

[Anthony PERARD]

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.

Regards,

-- 
Anthony PERARD

Re: Bug in usbdevices option handling when BusID=8

[George Dunlap]

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?

I'm not sure "host:0x04.0x2" is a supported format.  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.

  -George

Re: Bug in usbdevices option handling when BusID=8

[Anthony PERARD]

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.

-- 
Anthony PERARD

Re: Bug in usbdevices option handling when BusID=8

[George Dunlap]

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