USB passthrough test reports in 7.5RC1

olivierlambert

Great news!

Feel free to update the wiki to add this info

FrCo

@redalert11 Thank you, I can now add my AEOTEC Z-wave key to my jeedom VM.

But this key doesn't appear in my debian 9 VM.

On my server :

lsusb
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 003: ID 0658:0200 Sigma Designs, Inc.
Bus 005 Device 002: ID 10d5:5a08 Uni Class Technology Co., Ltd
Bus 005 Device 003: ID 0624:0248 Avocent Corp. Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Sigma Designs is my USB key I want in my VM.
Thanks to @redalert11, I enable the passthroud in XC-ng center.
I attach the Sigma Designs key to my Jeedom VM (under Debian 9)

I start the VM.

lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Sigma Designs is missing.
Any Idea ? (tried with Debian 8, and Ubuntu 18.04 LTS, Windows 10 same problem).

But no problem when I passthrough the same aeotec key on a Debian9 vm under vmware

kcah427

First, I want to say thanks to @fjen, @redalert11, and @FrCo for providing this information. It has certainly gotten me closer to USB pass through with a Linux VM.

@FrCo or @redalert11: were either of you able to get your AEOTEC Z-wave 5 gen USB to show as a device in your guest VM?

I followed the instructions above and was able to configure USB Pass through in XCP-ng Center, however in my CentOS 7.6 guest VM I only ever see the following devices:

[root@centos7.6 ~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I also checked dmesg and didn't find a single trace that it attempted to load the usb device.

alphatact1cs

Hello,
I am Georg, and I am also new to XCP, kind of...at work, we have XEN, but sadly, thats not my business.

Long story short, I got nearly everything sorted out, but not USB passthrough.
I got all devices showing up in XCP-center, and attached them to the VM.

When I start the VM, all USB devices are attached. But as soon as the VM is booting, the status "Attached" changes to "No".
[VM -> Properties -> USB]

However, what I found out: for example, I attach my keyboard and pass it to my Windows vm: then why I can control the local XEN console with this keyboard I passed through?

And this error:
"Failed","Starting VM 'Windows 10 (64-bit) (1)'
Internal error: xenopsd internal error: Call to usb reset failed: Forkhelpers.Spawn_internal_error("usage: usb_reset.py attach [-h] -d DOMID -p PID [-r RESET_ONLY] device\nusb_reset.py attach: error: argument -r: expected one argument\n", "", _)
Time: 00:00:23","xcp-ng","Jun 29, 2019 12:05 AM"

axiom00

@kcah427 did you ever resolved this? I have the same result trying to pass a Conbee2 stick into an Ubuntu VM.

kcah427

@axiom00

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

olivierlambert

That's a solution

axiom00

@kcah427 Thanks for sharing your solution. I end up using a Raspberry Pi as a Socat host and passing the USB Zigbee stick over ethernet to the VM. Not ideal but it works.

jmccoy555

@kcah427 did you do anything special to pass through the USB card?

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.

ScottyXCPNG

Hi,

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

stormi

Thanks for the feedback and interesting findings. I have really little knowledge about all this, so I can't answer your questions. Maybe @r1 will have partial answers. Else this is an area where, at short term, I hope that the community, step by step, gets closer to a solution that we could implement.

ScottyXCPNG

Hi,

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

ScottyXCPNG

Update: I haven't been able to figure out how to tell qemu to use a USB1.x interface instead of USB2.x (EHCI) which would let me pass the device through, but I've found a different work around. The device I'm trying to pass through appears as a USB serial device. After I stumbled upon a page mentioning that you could tie an emulated serial port to a TCP socket I dug further and found that you can do

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.

ScottyXCPNG

Bonus: I just tried and snapshot/backup still works with the serial port tied in that way

olivierlambert

Nice workaround indeed!! Well done and thanks a lot for reporting your progress, that's essential for the whole community

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

axiom00

@ScottyXCPNG Do you mind sharing details on how you attached your Conbee 2 stick? My setup is a vm Ubuntu running deconz in docker. deconz "see" the stick as a raspbee gateway and the channel is set to 0. Hence I cannot pair anything. Clicking on the channel set button doesn't do anything. deconz log show invalid current channel 0 (todo) repeatedly.

ScottyXCPNG

@axiom00 yes, once I dug further I had the same issues. I don't have anything to pair with my stick yet, I was trying to get it working before splashing out on zigbee devices. I'm not sure why it's having issues. If you look at the Conbee serial protocol it's all done via binary commands sent over 38400 baud serial, so it should work OK. I also had an issue where my stick disconnected/reconnected after about an hour and came up with a different path in /dev so it didn't attach any more. I suspect this was because qemu was holding the original device open.

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.

ScottyXCPNG

Further update: I've found the USB device is added to qemu after the vm has started through hot plugging. It seems this is done in xenopsd. It even has explicit code to support USB v1 devices in there

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)

olivierlambert

Can you create an issue asking for this detailed change to be made? We can create a test package with this change, so it won't impact other users

ScottyXCPNG

@olivierlambert created https://github.com/xcp-ng/xcp/issues/342 under xcp project. Thanks!

ScottyGuy created this issue in xcp-ng/xcp

USB passthrough test reports in 7.5RC1

closed Please create test packages to help with USB support (related to CA-328130 ) #342