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
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
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.
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
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
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 xenfvCould 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
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
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
xen@bugs.xenproject.org
2013-Aug-06 09:30 UTC
Processed: Re: Bug in usbdevices option handling when BusID=8
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 0Set title for #15 to `qemu-traditional mis-parses host bus 8 as 0''> thanksFinished 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
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 xenfvI''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
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
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
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