Only USB3 controller is "passed through" yet all USB2 ports are

jpbaril

Renowned Member
Feb 7, 2015
38
1
73
Hi,

I have 3 USB controllers.
Code:
00:14.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB xHCI Controller [8086:8cb1]
    Subsystem: ASUSTeK Computer Inc. 9 Series Chipset Family USB xHCI Controller [1043:8534]
00:1a.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2 [8086:8cad]
    Subsystem: ASUSTeK Computer Inc. 9 Series Chipset Family USB EHCI Controller [1043:8534]
00:1d.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1 [8086:8ca6]
    Subsystem: ASUSTeK Computer Inc. 9 Series Chipset Family USB EHCI Controller [1043:8534]

I followed https://pve.proxmox.com/wiki/Pci_passthrough
Each USB controller is in its own IOMMU group.
My VM is a i440fx machine with seabios since I'm passing my iGPU to that machine and that my host CPU is Haswell.

I only pass one USB controller, the USB3 one, since passing the USB2 ones do not do anything.
Code:
hostpci0: 0000:00:14.0
Yet, by passing that controller all my host USB ports are passed to the VM, not just the USB3 ones.
That's a problem because I still need some USB ports on the host, even if just USB2.

Could it be something related to some host BIOS options ?


100.conf:
Code:
args: -device 'vfio-pci,host=00:02.0,addr=0x02,x-igd-opregion=on,x-igd-gms=1,rombar=0'
boot: order=ide2;scsi0;net0
cores: 4
cpu: Haswell-noTSX
hostpci0: 0000:00:14.0
ide2: none,media=cdrom
memory: 6144
meta: creation-qemu=7.1.0,ctime=1676422579
name: ubuntu-desktop
net0: virtio=AE:D2:D0:2B:46:D9,bridge=vmbr0
numa: 0
ostype: l26
scsi0: local-lvm:vm-100-disk-0,iothread=1,size=60G
scsihw: virtio-scsi-single
smbios1: uuid=6db545ee-4493-4d4b-be9e-51ed83f8fa44
sockets: 1
vga: none
vmgenid: d1303021-7c06-402f-b84d-b46c534255f9

lines changed in grub:
Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt video=efifb:off"
GRUB_TERMINAL=console

Thank you for your help.
 
This appears to be the way your motherboard is wired. It is very common that many USB ports (2.0, 3.0, 3.2 etc.) are connected to a single controller. Maybe the optional ports, those that require you to plugin a cable that leads to the front of the computer case, or additional ports that require a cable with a bracket for the back of the case, are connected to the other USB controllers? Can you share a link to the manual of your motherboard?
 
Passthrough of the whole controller only works with xHCI/3.0 and up, not with EHCI/USB2 and also not with OHCI/USB1.
If you need more controllers, you could buy another USB3-Controller-PCIE-Card (imho the better approach) or try with single-device/vendorid-passthrough (this should work with EHCI/USB2)
 
@leesteken https://dlcdnets.asus.com/pub/ASUS/...9_H97I-PLUS_UG_v2_web_only.pdf?model=h97iplus

@mr44er If only the USB3 controller was passed I would understand but the 3 controllers are passed altogether.

I can passthrough a single device, it's just that one of these devices is a speaker with integrated DAC -- I never used onboard soundcard -- and usually usb soundcards are an issue when passed to VMs because of latency.
Yet, I need to keep USB ports on the host, especially for connection with UPS.
 
Last edited:
If only the USB3 controller was passed I would understand but the 3 controllers are passed altogether.
I did not realize that this is what appears to be happening. Please check (and show) your IOMMU groups with for d in /sys/kernel/iommu_groups/*/devices/*; do n=${d#*/iommu_groups/*}; n=${n%%/*}; printf 'IOMMU group %s ' "$n"; lspci -nns "${d##*/}"; done.
You cannot share devices from the same IOMMU group between VMs or between VMs and the Proxmox host. If one device is passed through to a VM, the Proxmox host loses connection to all devices of the group for security isolation reasons.
 
If only the USB3 controller was passed I would understand but the 3 controllers are passed altogether.
If this is the case, then it is what leesteken said. It's wired together and can't be treated split/separated, regardless if it shows different IOMMU-groups.
Can you check further where physically plugged devices end up to? Mostly USB3 has blue slots, USB2 and USB1 other colors?
If you passthrough the USB3 Controller, all physical slots (wired to that) go into the vm. You have a small chance that other slots with different colors then are the (on the host remaining) USB2 slots, which then can be used for single-passthrough.
But technically still only USB3/XHCI can be used for pci-passthrough.
 
Last edited:
If this is the case, then it is what leesteken said. It's wired together and can't be treated split/separated, regardless if it shows different IOMMU-groups.
Can you check further where physically plugged devices end up to? Mostly USB3 has blue slots, USB2 and USB1 other colors?
If you passthrough the USB3 Controller, all physical slots (wired to that) go into the vm. You have a small chance that other slots with different colors then are the USB2 slots, which then can be used for single-passthrough.
All my USB devices are currently plugged into the USB2 ports (the 4 black USB ports that can be seen in section "1.7.1 Rear panel connectors" in my motherboard manual I posted). Yet, as I said, I only passedthrough the USB3 controller...
 
@leesteken I already wrote in the thread initial post that they are all on their own seperated IOMMU group.
Sorry for not being more observant. And you are not using pcie_acs_override, which invalidates the IOMMU group information?
All my USB devices are currently plugged into the USB2 ports (the 4 black USB ports that can be seen in section "1.7.1 Rear panel connectors" in my motherboard manual I posted). Yet, as I said, I only passedthrough the USB3 controller...
Often the USB2 ports are indirectly connected to a USB3 controller, then again your system (surprisingly) does have two separate USB2 controllers.
Do you see devices connected to those USB2 ports actually connected to those USB2 controllers or are they (indirectly) connected to the USB3 controller? Check with lsusb -t and ls /dev/disk/by-path// in combination with a USB storage device.
 
And you are not using pcie_acs_override, which invalidates the IOMMU group information?
No. But since I'm also passing my iGPU, as per indications on Proxmox wiki (https://pve.proxmox.com/wiki/Pci_passthrough#IOMMU_Interrupt_Remapping), I eventually runned:
Code:
echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/iommu_unsafe_interrupts.conf
I don't know if it could have any effect on the USB contollers.
Often the USB2 ports are indirectly connected to a USB3 controller, then again your system (surprisingly) does have two separate USB2 controllers.
Do you see devices connected to those USB2 ports actually connected to those USB2 controllers or are they (indirectly) connected to the USB3 controller? Check with lsusb -t and ls /dev/disk/by-path// in combination with a USB storage device.
lsusb -t:
Code:
root@pve2:~# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 5: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/2p, 480M
    |__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 13: Dev 8, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 13: Dev 8, If 2, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 13: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 14: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 14: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
 
Last edited:
Do you happen to have a USB storage device, like a USB flash memory stick or something? Please try plugging it into the various USB2 ports and check with ls /dev/disk/by-path/ to which controller (PCI ID) they are connected. You probably need to do this on the Proxmox host without passthrough or any USB controller, unless you run Linux on the VM with passthrough (and check this inside the VM).
 
I'm still not convinced (after checking the manual) that this board has two separated controllers.

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M <- xhci and 5Gbit fits
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M <- xhci and 480Mbit doesn't fit, it's USB2-speed.
 
Do you happen to have a USB storage device, like a USB flash memory stick or something? Please try plugging it into the various USB2 ports and check with ls /dev/disk/by-path/ to which controller (PCI ID) they are connected. You probably need to do this on the Proxmox host without passthrough or any USB controller, unless you run Linux on the VM with passthrough (and check this inside the VM).
Code:
ls /dev/disk/by-path/ | grep usb
pci-0000:00:14.0-usb-0:14:1.0-scsi-0:0:0:0

@mr44er How to know for sure ?
 
How to know for sure ?
On the manual you posted, look page 21/84.
The table with IRQ assignments shows only one XHCI-controller and that's it.

Code:
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
So one of the xhci_hcd is lying and I guess it's the second. :)

Also it's a small board from 2014, so just normal business if they tricked all the ports daisy chained together.
 
Last edited:
Thank you both. It looks like I'll have to throw the towel.

In the end it's not that bad. I don't know if it's because virtualization technologies got improved or if because Linux VMs were always better with sound from virtualized usb devices, but compared with my past experiments with Windows VMs, the sound coming out is totally okay for system sounds, and almost perfect when watching videos: barely noticeable delay and very brief little scratch noise every few minutes.

I decided the have Ubuntu as a VM instead of the other way around as until now so I'll have to live with the inconveniences of that decision.
 
Last edited:
  • Like
Reactions: mr44er
In general AMD was and is still more generous with features on consumer stuff, especially from that era. That means you'll find working AMD-Vi on 2012ish small boards like E-350 and E-450.
Also UEFI, USB3 and VT-d were still new back then...and not always ideally implemented, bug free or with virtualisation in mind. Small boards were designed to run as media boxes for Windows Media Edition, xbmc/kodi etc.