Re: [Xen-devel] Bug in usbdevices option handling when BusID=8

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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@xxxxxxxxxx> 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

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