Details

Reviewers

None

Group Reviewers

Summary

This patch introduces userspace-only USB passthrough using libusb. It
supports configuring passthrough via a (passthru.vid.pid) tuple.
Currently, only vendor and product ID-based selection is implemented;
selecting specific ugen devices (to differentiate between identical
devices) would require changes to libusb.

All USB transfer types—control, bulk, interrupt, and isochronous—are
supported. Hotplugging is also handled, allowing devices to be unplugged
when guest startup and replugged afterward without issue.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 66817
Build 63700: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I have to second the *wow* given I have started this myself not knowing you are working on it.

I'll be happy to contribute the code for ugen selector as I have multiple v/d duplicates on laptops. doesn't need libusb changes, just a bit more parsing and looping (assuming my code fits in yours).
ugen matching isn't ideal either as you unplug/plug things and the bus.addr change and you have to update the config file... If you meant adding ugen checks on top of v/d then...

I think some of the fixes should be factored out upfront and commit separately.

I'll definitively test this by the end of the week with smart cards, some licensing dongle (very weird thing), and some wifi dongles.

usr.sbin/bhyve/usb_passthru.c
484	Can we name them by what they are? vid/pid or idVendor / idProduct?

In D52166#1191842, @bz wrote:

I have to second the *wow* given I have started this myself not knowing you are working on it.

I'll be happy to contribute the code for ugen selector as I have multiple v/d duplicates on laptops. doesn't need libusb changes, just a bit more parsing and looping (assuming my code fits in yours).
ugen matching isn't ideal either as you unplug/plug things and the bus.addr change and you have to update the config file... If you meant adding ugen checks on top of v/d then...

I think some of the fixes should be factored out upfront and commit separately.

I'll definitively test this by the end of the week with smart cards, some licensing dongle (very weird thing), and some wifi dongles.

Ah, I think you want to get whole device list and find the correct libusb device.

You are right, If we select the ugen manually, the hotplug is unable to work unless the device has serial number.

I would like to separate the patches but I think it is more convenient for people to test now.

usr.sbin/bhyve/usb_passthru.c
484	The reason why it is called param1 and 2 is that we may have different backend other than passthru in the future (thought I can’t image any circumstance we need that). So param1 and 2 is more generic.

Also, thanks for helping me test it!

Minor fixes

Harbormaster completed remote builds in B66562: Diff 161041.Aug 27 2025, 3:35 PM

aokblast added inline comments.Aug 27 2025, 3:36 PM

usr.sbin/bhyve/pci_xhci.c
627	Interrupt is not always asserted when a TD is complete. Therefore, add this helps us confirm if it is really happens.
usr.sbin/bhyve/usb_passthru.c
542	No, the speed in xhci should be LOW -> 2, FULL -> 1. The usb_dev_speed enum is LOW -> 1, FULL -> 2.

markj added a subscriber: markj.Aug 27 2025, 3:52 PM

markj added inline comments.

usr.sbin/bhyve/usb_passthru.c
30	Can we please use usbpassthru or usb_passthru as the namespace prefix instead of upassthru? It's not much longer and is much more clear.

Rename upassthru -> usb_passthru

Harbormaster completed remote builds in B66577: Diff 161060.Aug 27 2025, 6:29 PM

bz added inline comments.Aug 27 2025, 8:09 PM

usr.sbin/bhyve/usb_passthru.c
30	I used uhost for the entire thing I had started. Not sure anymore where I got that idea from...

Fix various locking problem

Harbormaster completed remote builds in B66590: Diff 161098.Aug 28 2025, 6:31 AM

Add total number of xfer to xhci

Harbormaster completed remote builds in B66598: Diff 161114.Aug 28 2025, 2:50 PM

aokblast edited the test plan for this revision. (Show Details)Aug 28 2025, 3:05 PM

aokblast edited the test plan for this revision. (Show Details)

Fix windows related bug.

Harbormaster completed remote builds in B66639: Diff 161194.Aug 29 2025, 3:47 PM

I have tested on Windows and works fine. An interesting thing is that when I plug in a Linux Live CD. The UEFI shell recognize it and want me to install Linux:).

For some reason when passing through an SSD with a sata-to-usb3 adapter, it causes bhyve to crash when the Linux kernel is starting to boot.

However, regular usb3 mass storage works fine and is recognized.

In D52166#1193959, @kenrap_kennethraplee.com wrote:

For some reason when passing through an SSD with a sata-to-usb3 adapter, it causes bhyve to crash when the Linux kernel is starting to boot.

However, regular usb3 mass storage works fine and is recognized.

Could you please give me the following information?

usbconfig dump_all_desc of your device
can you use gdb to start bhyve and give me the stack trace when crashing?

In D52166#1193982, @aokblast wrote:

Could you please give me the following information?

Sure thing!

usbconfig dump_all_desc of your device

ugen0.16: <ULT-Best Best USB Device> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (0mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0300 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0009 
  idVendor = 0x174c 
  idProduct = 0x55aa 
  bcdDevice = 0x0100 
  iManufacturer = 0x0002  <ULT-Best>
  iProduct = 0x0003  <Best USB Device>
  iSerialNumber = 0x0001  <042209283168>
  bNumConfigurations = 0x0001 

 Configuration index 0

    bLength = 0x0009 
    bDescriptorType = 0x0002 
    wTotalLength = 0x0079 
    bNumInterfaces = 0x0001 
    bConfigurationValue = 0x0001 
    iConfiguration = 0x0000  <no string>
    bmAttributes = 0x00c0 
    bMaxPower = 0x0000 

    Interface 0
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x0008  <Mass storage>
      bInterfaceSubClass = 0x0006 
      bInterfaceProtocol = 0x0050 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x0f
       RAW dump: 
       0x00 | 0x06, 0x30, 0x0f, 0x00, 0x00, 0x00


     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x0f
       RAW dump: 
       0x00 | 0x06, 0x30, 0x0f, 0x00, 0x00, 0x00



    Interface 0 Alt 1
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0001 
      bNumEndpoints = 0x0004 
      bInterfaceClass = 0x0008  <Mass storage>
      bInterfaceSubClass = 0x0006 
      bInterfaceProtocol = 0x0062 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x0f
       RAW dump: 
       0x00 | 0x06, 0x30, 0x0f, 0x05, 0x00, 0x00


      Additional Descriptor

      bLength = 0x04
      bDescriptorType = 0x24
      bDescriptorSubType = 0x03
       RAW dump: 
       0x00 | 0x04, 0x24, 0x03, 0x00


     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x0f
       RAW dump: 
       0x00 | 0x06, 0x30, 0x0f, 0x05, 0x00, 0x00


      Additional Descriptor

      bLength = 0x04
      bDescriptorType = 0x24
      bDescriptorSubType = 0x04
       RAW dump: 
       0x00 | 0x04, 0x24, 0x04, 0x00


     Endpoint 2
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0083  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x0f
       RAW dump: 
       0x00 | 0x06, 0x30, 0x0f, 0x05, 0x00, 0x00


      Additional Descriptor

      bLength = 0x04
      bDescriptorType = 0x24
      bDescriptorSubType = 0x02
       RAW dump: 
       0x00 | 0x04, 0x24, 0x02, 0x00


     Endpoint 3
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0004  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0400 
        bInterval = 0x0000 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

      Additional Descriptor

      bLength = 0x06
      bDescriptorType = 0x30
      bDescriptorSubType = 0x00
       RAW dump: 
       0x00 | 0x06, 0x30, 0x00, 0x00, 0x00, 0x00


      Additional Descriptor

      bLength = 0x04
      bDescriptorType = 0x24
      bDescriptorSubType = 0x01
       RAW dump: 
       0x00 | 0x04, 0x24, 0x01, 0x00

can you use gdb to start bhyve and give me the stack trace when crashing?

(gdb) bt
#0  thr_kill () at thr_kill.S:4
#1  0x00000fcff3a4b4c4 in __raise (s=s@entry=6) at /usr/src/lib/libc/gen/raise.c:48
#2  0x00000fcff3afda19 in abort () at /usr/src/lib/libc/stdlib/abort.c:61
#3  0x00000fcff3a2e271 in __assert (func=<optimized out>, file=<optimized out>, line=line@entry=730, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:47
#4  0x00000fc7ca071199 in usb_passthru_data_handler (scarg=<optimized out>, xfer=0x14bea94065c0, dir=<optimized out>, epctx=<optimized out>) at /usr/src/usr.sbin/bhyve/usb_passthru.c:730
#5  0x00000fc7ca06a9aa in pci_xhci_try_usb_xfer (sc=sc@entry=0x14bea4efb000, dev=dev@entry=0x14bea4f07000, devep=devep@entry=0x14bea4f07150, ep_ctx=<optimized out>, slot=slot@entry=1, epid=8)
    at /usr/src/usr.sbin/bhyve/pci_xhci.c:1756
#6  0x00000fc7ca06a769 in pci_xhci_handle_transfer (sc=0x14bea4efb000, dev=0x14bea4f07000, devep=0x14bea4f07150, ep_ctx=0xfd0fb85d100, trb=<optimized out>, slot=1, epid=8, 
    addr=<optimized out>, ccs=<optimized out>, streamid=0) at /usr/src/usr.sbin/bhyve/pci_xhci.c:1972
#7  pci_xhci_device_doorbell (sc=sc@entry=0x14bea4efb000, slot=1, epid=8, streamid=streamid@entry=0) at /usr/src/usr.sbin/bhyve/pci_xhci.c:2096
#8  0x00000fc7ca068eaa in pci_xhci_dbregs_write (sc=0x14bea4efb000, offset=6, value=<optimized out>) at /usr/src/usr.sbin/bhyve/pci_xhci.c:2118
#9  pci_xhci_write (pi=<optimized out>, baridx=<optimized out>, offset=1188, size=<optimized out>, value=<optimized out>) at /usr/src/usr.sbin/bhyve/pci_xhci.c:2387
#10 0x00000fc7ca05b4ca in pci_emul_mem_handler (vcpu=<optimized out>, dir=<optimized out>, addr=<optimized out>, size=-164456054, val=0xfd8435e8ba8, arg1=0x0, arg2=0)
    at /usr/src/usr.sbin/bhyve/pci_emul.c:595
#11 0x00000fc7ca04b70c in mem_write (vcpu=0x1d18b, gpa=80, wval=8, size=-164456054, arg=0x0, arg@entry=0x14bea7c010d8) at /usr/src/usr.sbin/bhyve/mem.c:162
#12 0x00000fc7ca083ef2 in emulate_mov (vcpu=0x1d18b, gpa=6, vie=<optimized out>, memread=<optimized out>, memwrite=0xfc7ca04b6d0 <mem_write>, arg=0x14bea7c010d8)
    at /usr/src/sys/amd64/vmm/vmm_instruction_emul.c:535
#13 vmm_emulate_instruction (vcpu=0x1d18b, vcpu@entry=0x14bea4e0d0c0, gpa=6, gpa@entry=3221243044, vie=<optimized out>, paging=<optimized out>, memread=<optimized out>, 
    memwrite=0xfc7ca04b6d0 <mem_write>, memarg=0x14bea7c010d8) at /usr/src/sys/amd64/vmm/vmm_instruction_emul.c:1787
#14 0x00000fc7ca04b089 in emulate_mem_cb (vcpu=0x1d18b, vcpu@entry=0x14bea4e0d0c0, paddr=6, paddr@entry=3221243044, mr=<optimized out>, arg=arg@entry=0xfd8435e8d40)
    at /usr/src/usr.sbin/bhyve/mem.c:248
#15 0x00000fc7ca04af7d in access_memory (vcpu=vcpu@entry=0x14bea4e0d0c0, paddr=3221243044, cb=0xfc7ca04b060 <emulate_mem_cb>, arg=arg@entry=0xfd8435e8d40) at /usr/src/usr.sbin/bhyve/mem.c:226
#16 0x00000fc7ca04ae3f in emulate_mem (vcpu=0x1d18b, vcpu@entry=0x14bea4e0d0c0, paddr=6, vie=vie@entry=0xfd8435e8f10, paging=paging@entry=0xfd8435e8ef8) at /usr/src/usr.sbin/bhyve/mem.c:260
#17 0x00000fc7ca073633 in vmexit_inst_emul (ctx=<optimized out>, vcpu=0x14bea4e0d0c0, vmrun=<optimized out>) at /usr/src/usr.sbin/bhyve/amd64/vmexit.c:377
#18 0x00000fc7ca043c60 in vm_loop (ctx=0x14bea4e1b000, vcpu=0x14bea4e0d0c0) at /usr/src/usr.sbin/bhyve/bhyverun.c:653
#19 0x00000fc7ca0429e7 in fbsdrun_start_thread (param=0x14bea4e1c078) at /usr/src/usr.sbin/bhyve/bhyverun.c:563
#20 0x00000fcff0d20eab in thread_start (curthread=0x14bea4a62810) at /usr/src/lib/libthr/thread/thr_create.c:299
#21 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0xfd8435e9000

Honor different configuration.

Harbormaster completed remote builds in B66711: Diff 161287.Aug 31 2025, 11:49 AM

Hello, could you please try again. I forget to adopt multiple configurations.

lwhsu added inline comments.Aug 31 2025, 12:55 PM

usr.sbin/bhyve/pci_xhci.c
1174	Is this intentional?
1556–1557	pcif?

Set PCD for FreeBSD

Harbormaster completed remote builds in B66718: Diff 161294.Aug 31 2025, 5:29 PM

Set PCD to report port status change

Harbormaster completed remote builds in B66719: Diff 161295.Aug 31 2025, 5:30 PM

aokblast added inline comments.Aug 31 2025, 5:32 PM

usr.sbin/bhyve/pci_xhci.c
1174	I think I will delete this field since Winodows, Linux, FreeBSD does not enable CIE at all.

In D52166#1194208, @aokblast wrote:

Hello, could you please try again. I forget to adopt multiple configurations.

With your latest changes, it does prevent bhyve from crashing. Appreciate it!

So, now it seems to create an additional 22 second stall at boot compared to without passing through the ssd with usb adapter.

When fully booted, it seems like it doesn't recognize it as if it weren't passthru'd.

In D52166#1194385, @kenrap_kennethraplee.com wrote:

In D52166#1194208, @aokblast wrote:

Hello, could you please try again. I forget to adopt multiple configurations.

With your latest changes, it does prevent bhyve from crashing. Appreciate it!

So, now it seems to create an additional 22 second stall at boot compared to without passing through the ssd with usb adapter.

When fully booted, it seems like it doesn't recognize it as if it weren't passthru'd.

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

I'm still going through the code, but here's a few preliminary comments :)

Thanks for working on this!

usr.sbin/bhyve/pci_xhci.c
2047–2050	`dev->dev_ue` should always be set no?
2811
usr.sbin/bhyve/usb_emul.h
54	Could you elaborate on what this is in a comment? (nit: also missing tab)
usr.sbin/bhyve/usb_passthru.c
32	imo `is_in` or something would be clearer. But also, what value should a control endpoint have here, since it is bidirectional?
224	Should be after `done:` label
424	This isn't the only failure case for `libusb_init_context`, right? I fear this error might be too specific and cause confusion. Maybe you wanna use `libusb_error_name` here.
435–441	perhaps we should do some input validation here for param1/2
446	nit: `vid=%0lx pid=%0lx` would make things more obvious for people encountering this error message
458–462	You can use `UD_IS_USB2/3` here (this just checks the major so you're fine w.r.t. `>=`). Also, is it fine to set the USB version to 2 if bcdUSB is `0x0110` e.g.?
463	nit: I kinda feel like an explicit `configured` member per endpoint would be clearer instead of setting the type values to -1. But I don't feel strongly about this
494–495	You are turning the libusb error code into a USB error code in `usb_passthru_guest_attach_device` with `libusb_error_to_usb_error`, so guessing you meant to check `!= USB_ERR_NORMAL_COMPLETION`
806–807	Clearer if `type & 3` was `UE_GET_XFERTYPE`. Didn't find an equivalent macro for checking if type is in/out, but it would be nice to add one if doesn't exist

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

In D52166#1195408, @aokblast wrote:

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

Gotcha, thanks for clarifying: Here is the report (3911 lines): https://gist.github.com/kenrap/ecfc003562bd8717900a46de4903d7bf

Fixes from comment

Harbormaster completed remote builds in B66784: Diff 161435.Sep 3 2025, 4:06 PM

Thanks @obiwac!

usr.sbin/bhyve/usb_passthru.c
32	Since it is for data only (bulk, intr, and isoc). Therefore, we don't have to care about control endpoint in here. For control xfer (endpoint 1), we will call ue_request instead of ue_data. I think a control endpoint other than ep number 1 is undefined behavior.
458–462	The xhci itself have two controller. One is for usb 1.0, 2.0 devices, another is for usb 3 devices. Setting the value to here is just for helping us know which controller should we use. If you open in a Windows Guest. You will see there is a xHCI and a eHCI even if we only have a xHCI instance. So setting the value 2 is fine here. Also, the bcdUSB returns from the libusb is just a uint16_t instead of a uint8_t[2], so I think UD_IS_USB2 will not work?

In D52166#1195426, @kenrap_kennethraplee.com wrote:

In D52166#1195408, @aokblast wrote:

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

Gotcha, thanks for clarifying: Here is the report (3911 lines): https://gist.github.com/kenrap/ecfc003562bd8717900a46de4903d7bf

Could you please check if it works now?

In D52166#1195497, @aokblast wrote:

In D52166#1195426, @kenrap_kennethraplee.com wrote:

In D52166#1195408, @aokblast wrote:

In D52166#1195391, @kenrap_kennethraplee.com wrote:

In D52166#1195280, @aokblast wrote:

Hello, could you please set the xhci_debug=1 and usb_passthru_debug=1 in bhyve and send me the report? The report maybe very long I think.

Quick question. How can I go about setting those options and generating the report using vm-bhyve? I already patched it using the diff from your github PR.

Hello, sorry it is from the code directly since it works like the normal DPRINTF. xhci_debug is in pci_xhci.c. usb_passthru_debug is in usb_passthru.c

Gotcha, thanks for clarifying: Here is the report (3911 lines): https://gist.github.com/kenrap/ecfc003562bd8717900a46de4903d7bf

Could you please check if it works now?

No change in behavior. Here is a new report: https://gist.github.com/kenrap/a39b327616560bfd5edb816960953d4d

Fix primary stream id failed

Harbormaster completed remote builds in B66817: Diff 161514.Sep 4 2025, 2:01 PM

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

No worries, I want to make sure this gets done right. I'll be your beta tester for this. 👍

I'm rebuilding my src tree now.

No difference. The report: https://gist.github.com/kenrap/9a1c406d097aa12c7a7b7ebe106cb681

Release max number of Pstreams

Harbormaster completed remote builds in B66818: Diff 161520.Sep 4 2025, 3:34 PM

In D52166#1196057, @kenrap_kennethraplee.com wrote:

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

No worries, I want to make sure this gets done right. I'll be your beta tester for this. 👍

I'm rebuilding my src tree now.

Thanks. I really need to get a device with stream in their descriptor. Could you please try again.

In D52166#1196089, @aokblast wrote:

In D52166#1196057, @kenrap_kennethraplee.com wrote:

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

No worries, I want to make sure this gets done right. I'll be your beta tester for this. 👍

I'm rebuilding my src tree now.

Thanks. I really need to get a device with stream in their descriptor. Could you please try again.

So, there is good news and bad news.

Good news is, the boot time went down significantly to 6 seconds.

The bad news, the device is still not detected by the guest OS.

Another report: https://gist.github.com/kenrap/2ad9fc1a216e0c6f7eb089c4f3b44c5f

In D52166#1196117, @kenrap_kennethraplee.com wrote:

In D52166#1196089, @aokblast wrote:

In D52166#1196057, @kenrap_kennethraplee.com wrote:

In D52166#1196056, @aokblast wrote:

Sorry, I know that it is a little bit annoying. But since I don't have such device. Could you please try again?

No worries, I want to make sure this gets done right. I'll be your beta tester for this. 👍

I'm rebuilding my src tree now.

Thanks. I really need to get a device with stream in their descriptor. Could you please try again.

So, there is good news and bad news.

Good news is, the boot time went down significantly to 6 seconds.

The bad news, the device is still not detected by the guest OS.

Another report: https://gist.github.com/kenrap/2ad9fc1a216e0c6f7eb089c4f3b44c5f

Hello: Does your device work on FreeBSD host? I saw a transfer is cancelled so the problem maybe on the libusb side or kernel stack.

In D52166#1196153, @aokblast wrote:

Hello: Does your device work on FreeBSD host? I saw a transfer is cancelled so the problem maybe on the libusb side or kernel stack.

Sorry for the late reply. Yes, I'm able to mount the device on my FreeBSD host.

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

In D52166#1196949, @aokblast wrote:

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

Appreciate the heads up. I'll be on standby.

Hi, I've tested this with a licensing dongle and a smart card reader on an external USB HUB with Windows 11. Licensing worked, smart card was detected correctly. I am still wondering if param1/2 in the config are the best thing but they work, so be it. Many thanks to you and the FreeBSD Foundation! I'll keep trying and using it for other bits as well the next days on other machines. I just need to disable the debugging as my remote window kept scrolling (have the tablet on for vnc as well in this case) like I was on a 9600 connection downloading Netscape ;-)

avg added a subscriber: avg.Nov 11 2025, 3:13 PM

olevole_olevole.ru added a subscriber: olevole_olevole.ru.Nov 21 2025, 12:38 PM

It's gotten silent here. May I ask what the plan is? Is there a chance to get this work into 16?

In D52166#1232521, @bz wrote:

It's gotten silent here. May I ask what the plan is? Is there a chance to get this work into 16?

Hello. I received the notice of conscription for 4 month obligatory military service in my country in late Octorber which have started from November. I will continue to work on this after my service.

bhyve: implement single USB device passthrough support
Needs ReviewPublic
Actions

Details

Diff Detail

Event Timeline

Revision Contents
Changeset List

Diff 161514

usr.sbin/bhyve/Makefile

usr.sbin/bhyve/Makefile.depend

usr.sbin/bhyve/pci_xhci.c

usr.sbin/bhyve/usb_emul.h

usr.sbin/bhyve/usb_emul.c

usr.sbin/bhyve/usb_mouse.c

usr.sbin/bhyve/usb_passthru.c

bhyve: implement single USB device passthrough supportNeeds ReviewPublicActions

Details

Diff Detail

Event Timeline

Revision ContentsChangeset List

Diff 161514

usr.sbin/bhyve/Makefile

usr.sbin/bhyve/Makefile.depend

usr.sbin/bhyve/pci_xhci.c

usr.sbin/bhyve/usb_emul.h

usr.sbin/bhyve/usb_emul.c

usr.sbin/bhyve/usb_mouse.c

usr.sbin/bhyve/usb_passthru.c

bhyve: implement single USB device passthrough support
Needs ReviewPublic
Actions

Revision Contents
Changeset List