In D49587#1235795, @olce wrote:

In D49587#1235740, @aokblast wrote:

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes.

Mmm... It's not that providing it only on CPU 0 does not make sense, but actually having a different knob for each CPU can be useful (admittedly in corner cases), and would be consistent with hwpstate_intel. But that's of course not a blocker, this can be added back later on.

Going to review the new version.

@markj Please also help me review it when you have time, thanks! Also, I remember that you have told me that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

If Mark gives no answer in a few days, I'll suggest something.

Minor fixes

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes. @markj Please also help me review it when you have time, thanks! Also, I remember that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

Expose the epp interface in only cpu 0 and modify all cpu value.

Make sense to me.

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?

LGTM.

In D52815#1206854, @imp wrote:

I suspect this is fine. ISA is all the on boatd IO that's ioport mapped that's not part of pci. It most likely is lpc based and the ACPI enumeration of that jardware should hang off this bus, not the acpi bus for the software model. But practically, this is easier and there's not enough difference to mater.

@jhb do you think that it is fine? Since you know much about pcie, and isa is the predecessor of pci(e).

I think nobody cares about isa bus stuff.
Also, no modern hardware attaches to isa bridge actually.
But it is really annoying for me to see "none" in pciconf -lv.

In D52423#1197210, @emaste wrote:

The wrapping is a bit awkward and I think style(9)'s allowance for an exception to the 80 col width could be warranted here, if you agree.

        } else if ((id == HDA_CODEC_ALC295 && subid == FRAMEWORK_LAPTOP_0005_SUBVENDOR) ||
            (id == HDA_CODEC_ALC285 && subid == FRAMEWORK_LAPTOP_000D_SUBVENDOR)) {             
                                                                                
``

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#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

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.

Release max number of Pstreams

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

Fix primary stream id failed

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

Thanks @obiwac!

Fixes from comment

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.

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.

Follow xHCI document

Set PCD to report port status change

Set PCD for FreeBSD

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

Minor updates

Honor different configuration.

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.

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:).

Fix windows related bug.

This implemented is problematic since the correct way is to append a zero size TRB in TD instead of creating new TD. However, I think I am unable to make it work before 15.0 release. Therefore, I will modify it to at least we won't break any ABI for 15 if we want to merge later.

No clear in reset

Add total number of xfer to xhci

Fix various locking problem

Destroy mutex

Rename upassthru -> usb_passthru

Use (void)

Formatting

Use int

Minor fixes

Add missing ue_cancel

Minor fixes

Minor fixes

In D47930#1191301, @phil wrote:

Why do you need this on xo_buf.h, an internal file?

In the FWIW department: It always seems odd that C++ needs decoration in non-C++ files, rather that have this knowledge in compiler command line arguments (e.g. "--c-include /usr/include").

Thanks,
Phil

Also, thanks for helping me test it!

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.

In D52166#1191818, @ziaee wrote:

Wow this is exciting! How do we use this? Can we put it in the manual?

Reorder include

FOrmatting

Format fixes

Remove useless constant

In D52049#1191173, @markj wrote:

In D52049#1191172, @aokblast wrote:

In D52049#1191168, @markj wrote:

I think it's ok, thank you.

One thing I am not sure about: should we just compile the new driver into ichwd.ko rather than create a new kernel module? I do not think it is a major issue, but personally I would probably just fold this into ichwd.ko to keep the diff smaller. I leave it up to you.

I never do that before. Can I define two modules inside a ko? I know that the kernel module is done through special ELF section and will be handled by kernel loader. I don't know if the linker works on combining these two into a single section.

Yes! It is a bit confusing, but there are two distinct concepts, linker files (i.e., ELF files which the kernel can load, so a .ko file) and modules (typically drivers). A linker file can contain multiple modules. kldstat -v will list the modules in each linker file, e.g.,:

4    1 0xffffffff8227d000   380300 vmm.ko (/boot/kernel.GENERIC-NODEBUG/vmm.ko)
       Contains modules:                                                                                                                                      
                Id Name                                                                                                                                       
                 6 acpi/ivhd                                                                                                                                  
                 5 pci/amdviiommu   
                 4 pci/ppt                                                                                                                                    
                 3 vmm                                                                                                                                        
5    1 0xffffffff825fe000   61fa88 zfs.ko (/boot/kernel.GENERIC-NODEBUG/zfs.ko)                                                                               
       Contains modules:                                                                                                                                      
                Id Name                                                                                                                                       
                 7 zfsctrl                                                                                                                                    
                 9 zfs                                                                                                                                        
                10 zfs_zvol
                 8 zfs_vdev

Confusingly, to most people "kernel module" means "linker file." Usually the distinction is not important, and usually a linker file contains only one module.

Merge driver to ichwd

In D52049#1191168, @markj wrote:

I think it's ok, thank you.

One thing I am not sure about: should we just compile the new driver into ichwd.ko rather than create a new kernel module? I do not think it is a major issue, but personally I would probably just fold this into ichwd.ko to keep the diff smaller. I leave it up to you.

Add manual

Add missing x86 file