The devices we want to pass-through:

• Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
  Which apparently is technical speak for a RFXtrx433XL USB 433.92MHz Transceiver
• Prolific Technology, Inc. PL2303 Serial Port
  Which apparently is technical speak for a ZiGate USB-TTL
• Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB

I'm using XCP-ng Center 20.04.00 to help me out and XCP-NG 8.1 on the host.

Let's start with a good old:

[12:56 vmhost ~]# xe pusb-list host-uuid=*****
uuid ( RO)            : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0
            path ( RO): 1-2
       vendor-id ( RO): 067b
     vendor-desc ( RO): Prolific Technology, Inc.
      product-id ( RO): 2303
    product-desc ( RO): PL2303 Serial Port
          serial ( RO):
         version ( RO): 1.10
     description ( RO): Prolific Technology, Inc._PL2303 Serial Port


uuid ( RO)            : 08b23122-e01b-9ab2-e72d-185648ae19d7
            path ( RO): 1-7
       vendor-id ( RO): 0403
     vendor-desc ( RO): Future Technology Devices International, Ltd
      product-id ( RO): 6015
    product-desc ( RO): Bridge(I2C/SPI/UART/FIFO)
          serial ( RO): *******
         version ( RO): 2.00
     description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG

Ok, we have 2 devices already ready to be passthrough. Let's try to make the third one show up!
Using the follow commands and some reading I could identify the DENY rules in "/etc/xensource/usb-policy.conf", which prevent my Aeotec Z-Stick from showing.

[13:06 vmhost ~]# /opt/xensource/libexec/usb_scan.py -d
[13:06 vmhost ~]# cat /var/log/user.log | less

I've adjusted my "/etc/xensource/usb-policy.conf" to the following:

# When you change this file, run 'xe pusb-scan' to confirm
# the file can be parsed correctly.
#
# Syntax is an ordered list of case insensitive rules where # is line comment
#  and each rule is (ALLOW | DENY) : ( match )*
#  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
#
# USB Hubs (class 09) are always denied, independently of the rules in this file
DENY: vid=17e9 # All DisplayLink USB displays
ALLOW:vid=0658 pid=0200 class=02 # Aeotec Z-Stick Gen5 (ZW090) - UZB
DENY: class=02 # Communications and CDC-Control
ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
DENY: class=03 subclass=01 prot=02 # HID Boot mice
ALLOW:vid=0658 pid=0200 class=0a # Aeotec Z-Stick Gen5 (ZW090) - UZB
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
DENY: class=ef subclass=04 # Miscellaneous network devices
ALLOW: # Otherwise allow everything else

but also tried:

# When you change this file, run 'xe pusb-scan' to confirm
# the file can be parsed correctly.
#
# Syntax is an ordered list of case insensitive rules where # is line comment
#  and each rule is (ALLOW | DENY) : ( match )*
#  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
#
# USB Hubs (class 09) are always denied, independently of the rules in this file
DENY: vid=17e9 # All DisplayLink USB displays
ALLOW:vid=0658 pid=0200 # Aeotec Z-Stick Gen5 (ZW090) - UZB
ALLOW: class=02 # Communications and CDC-Control
ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
DENY: class=03 subclass=01 prot=02 # HID Boot mice
ALLOW: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
DENY: class=ef subclass=04 # Miscellaneous network devices
ALLOW: # Otherwise allow everything else

After some playing around we got:

[13:14 vmhost ~]# xe pusb-scan host-uuid=*****
[13:15 vmhost ~]# xe pusb-list host-uuid=*****
uuid ( RO)            : 0f7d6f12-6c4e-4f71-0c81-f7a7503a75f1
            path ( RO): 1-8
       vendor-id ( RO): 0658
     vendor-desc ( RO): Sigma Designs, Inc.
      product-id ( RO): 0200
    product-desc ( RO): Aeotec Z-Stick Gen5 (ZW090) - UZB
          serial ( RO):
         version ( RO): 2.00
     description ( RO): Sigma Designs, Inc._Aeotec Z-Stick Gen5 (ZW090) - UZB


uuid ( RO)            : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0
            path ( RO): 1-2
       vendor-id ( RO): 067b
     vendor-desc ( RO): Prolific Technology, Inc.
      product-id ( RO): 2303
    product-desc ( RO): PL2303 Serial Port
          serial ( RO):
         version ( RO): 1.10
     description ( RO): Prolific Technology, Inc._PL2303 Serial Port


uuid ( RO)            : 08b23122-e01b-9ab2-e72d-185648ae19d7
            path ( RO): 1-7
       vendor-id ( RO): 0403
     vendor-desc ( RO): Future Technology Devices International, Ltd
      product-id ( RO): 6015
    product-desc ( RO): Bridge(I2C/SPI/UART/FIFO)
          serial ( RO): *****
         version ( RO): 2.00
     description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG

Well we're ready for some pass-through, right?

Using XCP-ng Center we can see these 3 devices and "Enable pass-through" for all of these 3 devices. After shutting down the VM, using properties we can attach all 3 USB-devices and start the VM again, but not before running the following command as was recommended:

xe vm-param-set uuid=**** platform:device-model=qemu-upstream-compat

Let's start and monitor dmesg:

[  742.309309] block tda: sector-size: 512/512 capacity: 20971520
[  742.727012] device vif6.0 entered promiscuous mode
[  742.961272] device tap6.0 entered promiscuous mode
[  743.068536] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
[  743.217985] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
[  743.376482] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
[  743.525903] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
[  743.571126] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  743.571136] ftdi_sio 1-7:1.0: device disconnected
[  743.700284] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
[  743.851993] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
[  743.852018] usb 1-7: Detected FT-X
[  743.852171] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
[  743.984286] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
[  744.137611] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
[  744.138491] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  744.138500] ftdi_sio 1-7:1.0: device disconnected
[  744.268258] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
[  744.420007] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
[  744.420029] usb 1-7: Detected FT-X
[  744.420464] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
[  744.465529] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
[  744.465539] pl2303 1-2:1.0: device disconnected
[  744.592213] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
[  744.741634] pl2303 1-2:1.0: pl2303 converter detected
[  744.742254] usb 1-2: pl2303 converter now attached to ttyUSB1
[  744.876149] usb 1-8: reset full-speed USB device number 4 using xhci_hcd
[  745.025388] cdc_acm 1-8:1.0: ttyACM0: USB ACM device
[  745.025629] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  745.025636] ftdi_sio 1-7:1.0: device disconnected
[  745.156079] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
[  745.307475] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
[  745.307495] usb 1-7: Detected FT-X
[  745.307652] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
[  745.308046] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
[  745.308054] pl2303 1-2:1.0: device disconnected
[  747.307309] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  747.307318] ftdi_sio 1-7:1.0: device disconnected
[  747.435543] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
[  747.586967] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected
[  747.586987] usb 1-7: Detected FT-X
[  747.587202] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0
[  756.026324] device tap6.0 left promiscuous mode
[  756.744069] vif vif-6-0 vif6.0: Guest Rx ready
[  757.925017] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
[  758.321147] usb 1-2: reset full-speed USB device number 2 using xhci_hcd
[  768.745084] pl2303 1-2:1.0: pl2303 converter detected
[  768.746207] usb 1-2: pl2303 converter now attached to ttyUSB1
[  769.803089] device vif6.0 left promiscuous mode

And xensource.log as txt file while the VM started and got shutdown.

Oh and so far everything looked good, right? Everything got attached, the VM booted and the properties of the VM shows that all 3 devices are "Attached".

On the VM running ubuntu I get the following:

vm@vm:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 12M
        |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
    |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M

My USB 1.1 device (ZiGate) is present! The other 2 devices are USB2.0 and those are magically missing?! Why? How? What did I do wrong!? What can I try to make this work?

Ah well, time to pci-pass-through my USB controller into that device again, although I would have prefered USB-passthrough! I did also apply scottyXCPNG's workaround, but not allow my USB 2.0 devices to be passed into the VM with those applied.

--- /opt/xensource/libexec/usb_scan.py     2019-11-04 10:03:02.000000000 +0000
+++ /tmp/usb_scan.py    2020-03-01 17:32:29.266317478 +0000
@@ -152,10 +152,11 @@
     _CLASS = "bDeviceClass"
     _CONF_VALUE = "bConfigurationValue"
     _NUM_INTERFACES = "bNumInterfaces"
+    _USB_SPEED = "speed"
 
     _PRODUCT_DESC = [_DESC_VENDOR, _DESC_PRODUCT]
     _PRODUCT_DETAILS = [_VERSION, _ID_VENDOR, _ID_PRODUCT, _BCD_DEVICE, _SERIAL,
-                        _CLASS, _CONF_VALUE, _NUM_INTERFACES]
+                        _CLASS, _CONF_VALUE, _NUM_INTERFACES, _USB_SPEED]
     _PROPS = _PRODUCT_DESC + _PRODUCT_DETAILS
     _PROPS_NONABLE = _PRODUCT_DESC + [_SERIAL]
 
@@ -590,7 +591,10 @@
 
     pusb["path"] = device.get_node()
     # strip the leading space of "version"
-    pusb["version"] = device[UsbDevice._VERSION].strip()
+    if int(device[UsbDevice._USB_SPEED]) <= 12:
+        pusb["version"] = "1.00"
+    else:
+        pusb["version"] = device[UsbDevice._VERSION].strip()
     pusb["vendor-id"] = device[UsbDevice._ID_VENDOR]
     pusb["product-id"] = device[UsbDevice._ID_PRODUCT]
     pusb["vendor-desc"] = device[UsbDevice._DESC_VENDOR]

in theory any deice which is "low" or "full" speed (i.e. USB1) will have it's version number changed to 1.00 which forces xenopsd to use a USB1 bus. It may have side effects if the driver in the guest relies on the version number so caveat emptor.

[15:28 xcp-ng-bywirlgr log]# diff -u /opt/xensource/libexec/usb_scan.py.orig /opt/xensource/libexec/usb_scan.py
--- /opt/xensource/libexec/usb_scan.py.orig     2019-11-04 10:03:02.000000000 +0000
+++ /opt/xensource/libexec/usb_scan.py  2020-03-01 15:20:53.323512746 +0000
@@ -590,7 +590,8 @@
 
     pusb["path"] = device.get_node()
     # strip the leading space of "version"
-    pusb["version"] = device[UsbDevice._VERSION].strip()
+    #pusb["version"] = device[UsbDevice._VERSION].strip()
+    pusb["version"] = "1.00"
     pusb["vendor-id"] = device[UsbDevice._ID_VENDOR]
     pusb["product-id"] = device[UsbDevice._ID_PRODUCT]
     pusb["vendor-desc"] = device[UsbDevice._DESC_VENDOR]

I do NOT recommend this AT ALL. It is a gross hack. Apparently the xenopsd relies on the version number returned by the device to dictate the USB bus type of the controller it attaches to. I have no idea in what universe that makes sense.

The above only works for me as that is the only USB device attached to the HV. I guess I could make the code a little smarter by looking for a particular device ID and only over-riding the version then

According to xenopsd sources from 0.101.0 from the XCP-NG 8.0 SRPM, the code is

let vusb_plug ~xs ~privileged ~domid ~id ~hostbus ~hostport ~version =
  debug "vusb_plug: plug VUSB device %s" id;
  let get_bus v =
    if String.startswith "1" v then
      "usb-bus.0"
    else begin
      (* Here plug usb controller according to the usb version*)
      let usb_controller_driver = "usb-ehci" in
      let driver_id = "ehci" in
      vusb_controller_plug ~xs ~domid ~driver:usb_controller_driver ~driver_id;
      Printf.sprintf "%s.0" driver_id;
    end
  in
  if Qemu.is_running ~xs domid then
    begin
      (* Need to reset USB device before passthrough to vm according to CP-24616.
         Also need to do deprivileged work in usb_reset script if QEMU is deprivileged.
      *)
      begin match Qemu.pid ~xs domid with
        | Some pid -> usb_reset_attach ~hostbus ~hostport ~domid ~pid ~privileged
        | _ -> raise (Xenopsd_error (Internal_error (Printf.sprintf "qemu pid does not exist for vm %d" domid)))
      end;
      let cmd = Qmp.(Device_add Device.(
                     { driver = "usb-host";
                       device = USB {
                         USB.id = id;
                         params = Some USB.({bus = get_bus version; hostbus; hostport})
                       }
                     }
                  ))
      in qmp_send_cmd domid cmd |> ignore
    end

unfortunately I cannot find where the mysterious "version" parameter is that needs to be set to "1" to enable the use of USB bus 0 in the guest, which is USB 1. I'm wondering if it's stupidly reading the version string of the USB device itself rather than something else

I note that the latest code in the upstream xapi-project/xenopsd device.ml line 1818 is radically different and now has a "speed" parameter. This was added in commit ab15e6c3b1b06b2eac4f2a8be724eac50c9d4b22 in Oct 2019 for CA-328130 (whatever that is). It looks like code was also added to the upstream xapi-project/xenapi to add the "speed" parameter to the data model there. So there may be a fix in a future version of XCP-NG if they pull in these fixes. I haven't looked at 8.1-beta but I suspect it's too late to go making wholesale changes there if the code hasn't already been merged.

ok, just downloaded the SRPM from 8.1 xenopsd and it still has the old code for vusb plug, so I'm guessing 8.1 doesn't have this fixed (yet)

To remove the device from the vm again do

xe vm-param-remove vm-param-add uuid=<uuid> param-name=platform param-key=hvm_serial

else it won't start if the serial device isn't present.

edit: start a chat with me, I'd like to send you some goodies

xe vm-param-add uuid=<uuid> param-name=platform hvm_serial=/dev/ttyACM0

and hey presto your /dev/ttyS0 in the guest is now tied to the device on the hypervisor

I may still poke around and try and find a better solution but for now my needs appear to be satisfied.

Thanks for the reply @stormi

I've kind of hit a roadblock in my own probing so far. I was trying to figure out how the VUSB parameters got passed into qemu. The daemon.log shows it's run by forkexecd, but comparing the command of the same vm run with and without VUSB shows no real differences, so there must be a configuration file or other metadata being passed in with the VUSB passthrough configuration. I tried poking at the xenapi and quickly got lost in the ocaml code which I can't really read.

I've also found that a VM with a VUSB attached cannot be snapshotted and backed up, which is really unfortunate. I'm not entirely sure why that restriction exists. Surely if the VM is rolled back to the snapshot then the system can treat it the same as if the USB device vanishes? It seems that the system removes the VUSB attachment if the device vanishes so I would have thought the same could be done from snapshots or backups?

Thanks,

Gary

I have XCP-NG 8.0 loaded onto an Intel NUC and I'm trying to pass a USB device through to a guest V.M. Although the setup using the CLI seems to go OK, the guest never sees the device. I've tried 2 different guests with no success

Digging into the logs a bit more I found this:

Feb 15 14:20:49 xcp-ng-bywirlgr qemu-dm-17[18527]: qemu-dm-17: Warning: speed mismatch trying to attach usb device "ConBee II" (full speed) to bus "ehci.0", port "1" (high speed)

This seems to come from qemu-dp/hw/usb/bus.c:usb_check_attach() which sets the warning if the speed of the probed USB device is different to the speed of the emulated USB controller in the guest (at least that's what I think it does)

Despite the fact that it is classed as a warning, it appears to abort the attachment of the device to the guest in qemu-dp/hw/usb/bus.c:usb_device_attach() if the warning has been generated.

• is it possible to use one of the "xe vusb-param-*" commands to set the emulated USB bus to USB 1.x instead of 2.x (ehci)? I haven't been able to trace back where the bus is created yet

• if not, is it possible to comment out that check and see what happens? To be honest, the check puzzles me. It is perfectly valid to plug a FULL speed (USB1.x) device into a HIGH speed (USB2.x) or SUPER speed (USB3.x) bus and have it work normally. There might be some magic have to happen at the port level to make it work, but it works just fine as the USB 1.x device I'm trying to use is plugged into a USB 2.x port on my NUC

Any ideas?

Thanks,

Gary

I'm trying with a ASM1142 but can not boot the VM once it is assigned.

Is there a particular reason why you chose the card that you used?

Thanks.

I did a bit more research and determined that XCP-ng was passing the USB device through to the guest OS, although either didn't have the right drivers for my z-wave USB stick, or otherwise didn't know what to do with it; so it always just passed it to the guest as a root hub.

I wasn't particularly interested in spending too much more time on it so I purchased the following PCI-E card and passed the whole controller through to the guest. That solved my problem and it has been working ever since.

https://www.amazon.com/gp/product/B00JFR2H64/ref=ppx_yo_dt_b_asin_title_o05_s00