Unable to passthrough asmedia 2142 on taichi x470. Can I passthrough onboard USB on x570 Taichi?

I’ve tried everything. I’ve googled all day. Seems I’m not the only one with this problem with this controller.

Does the Asrock x570 Taichi have a onboard USB controller that I can passthrough?

I’m in a similar situation on an X470 Taichi with the latest 3.77 beta BIOS (AGESA Combo-AM4 1.0.0.4 Patch B). Since you mention both the X470 Taichi and the X570 Taichi, I’m not sure if this is relevant to you. Regardless, let’s soldier on and hope for the best.

On the X470 Taichi, the ASMedia ASM2142 is indeed trapped in a group with a bunch of other things that probably shouldn’t be passed through.

IOMMU Group 18:
    02:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:43d0] (rev 01)
    02:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller [1022:43c8] (rev 01)
    02:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge [1022:43c6] (rev 01)
    03:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
    03:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
    03:03.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
    03:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
    03:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
    04:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
    05:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
    06:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1184e PCIe Switch Port [1b21:1184]
    07:01.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1184e PCIe Switch Port [1b21:1184]
    07:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1184e PCIe Switch Port [1b21:1184]
    07:05.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1184e PCIe Switch Port [1b21:1184]
    07:07.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1184e PCIe Switch Port [1b21:1184]
    08:00.0 Network controller [0280]: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] [8086:24fb] (rev 10)
    0a:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03)

There are, however, a few other system devices that appear in their own groups. Of particular interest is the USB controller in group 24

IOMMU Group 24:
    11:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c]
IOMMU Group 25:
    11:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
IOMMU Group 26:
    12:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51)
IOMMU Group 27:
    13:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51)

My first attempt was to take the naive approach: blindly pass the device through to the VM (in virt-manager), power it on and hope for the best. Rather than give me a VM with physical USB ports I could plug stuff directly into, the host ended up crashing and burning in spectacular fashion.

This is where I’m at attempting to get to the bottom of this.

Looking for the PCI device in dmesg shows it gets assigned to both USB bus 7 and 8; presumably because USB 3.1 hardware presents as USB 3.1 and 2.0 devices.

$ dmesg | grep 11\:00\.3
[    0.197300] pci 0000:11:00.3: [1022:149c] type 00 class 0x0c0330
[    0.197319] pci 0000:11:00.3: reg 0x10: [mem 0xf7700000-0xf77fffff 64bit]
[    0.197349] pci 0000:11:00.3: enabling Extended Tags
[    0.197395] pci 0000:11:00.3: PME# supported from D0 D3hot D3cold
[    0.336226] pci 0000:11:00.3: Adding to iommu group 24
[    0.520342] xhci_hcd 0000:11:00.3: xHCI Host Controller
[    0.521687] xhci_hcd 0000:11:00.3: new USB bus registered, assigned bus number 7
[    0.523134] xhci_hcd 0000:11:00.3: hcc params 0x0278ffe5 hci version 0x110 quirks 0x0000000000000410
[    0.530280] usb usb7: SerialNumber: 0000:11:00.3
[    0.534565] xhci_hcd 0000:11:00.3: xHCI Host Controller
[    0.535943] xhci_hcd 0000:11:00.3: new USB bus registered, assigned bus number 8
[    0.537315] xhci_hcd 0000:11:00.3: Host supports USB 3.1 Enhanced SuperSpeed
[    0.545551] usb usb8: SerialNumber: 0000:11:00.3

Bus 7 and 8 don’t appear to be anything special.

$ dmesg | grep usb[78]
[    0.524758] usb usb7: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[    0.526143] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.527524] usb usb7: Product: xHCI Host Controller
[    0.528898] usb usb7: Manufacturer: Linux 5.3.0-24-generic xhci-hcd
[    0.530280] usb usb7: SerialNumber: 0000:11:00.3
[    0.538691] usb usb8: We don't know the algorithms for LPM for this host, disabling LPM.
[    0.540081] usb usb8: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.03
[    0.541454] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.542824] usb usb8: Product: xHCI Host Controller
[    0.544184] usb usb8: Manufacturer: Linux 5.3.0-24-generic xhci-hcd
[    0.545551] usb usb8: SerialNumber: 0000:11:00.3

lsusb shows the following

$ lsusb
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0aa7 Intel Corp.
Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 2: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 9: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 9: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

Cross referencing lsusb, lspci and dmesg (and physically plugging USB devices into ports on the machine for good measure), I get the following

USB bus PCI address Physical device USB speed
usb1 0000:02:00.0 PCH AMD USB 2.0
usb2 0000:02:00.0 PCH AMD USB 3.1
usb3 0000:04:00.0 PCH ASMedia ASM2142 USB 2.0
usb4 0000:04:00.0 PCH ASMedia ASM2142 USB 3.1
usb5 0000:0f:00.2 Nvidia GeForce GTX 1660 Ti USB 2.0
usb6 0000:0f:00.2 Nvidia GeForce GTX 1660 Ti USB 3.1
usb7 0000:11:00.3 CPU AMD USB 2.0
usb8 0000:11:00.3 CPU AMD USB 3.1

(If only the GTX 1660 Ti had a physical port I could plug something into :angry:…)

Intentionally starting the VM again while running top from a remote session shows things going… badly.

top - 19:59:29 up 29 min,  4 users,  load average: 29.68, 9.62, 3.41
Tasks: 410 total,  21 running, 389 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us, 10.4 sy,  0.0 ni, 82.9 id,  6.3 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  32103.7 total,  21348.0 free,   9755.3 used,   1000.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  21918.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1889 root     -51   0       0      0      0 R 100.0   0.0   1:07.99 irq/114-nvidia
 7050 libvirt+  20   0 9314328   8.0g  21584 R  90.6  25.7   1:56.90 qemu-system-x86
 5794 root      20   0       0      0      0 R  65.6   0.0   1:18.00 kworker/15:0+events
 7108 jason     20   0   20688   3988   3208 R  62.5   0.0   1:17.11 top
  117 root      25   5       0      0      0 S  62.5   0.0   0:44.99 ksmd
 1644 root      20   0 1592208  42276  30880 S  59.4   0.1   0:36.83 libvirtd
 1475 root      20   0   82012   3920   3428 S  56.3   0.0   0:22.37 irqbalance
   18 root      20   0       0      0      0 R  43.7   0.0   0:13.99 ksoftirqd/1
  610 root      19  -1   59820  25956  24288 S  43.7   0.1   0:30.48 systemd-journal
  627 root      20   0   21476   5448   3840 S  34.4   0.0   0:11.40 systemd-udevd
 1994 root      20   0  260672   9528   8180 R  28.1   0.0   0:09.24 upowerd
 5958 root      20   0       0      0      0 R  28.1   0.0   0:34.07 kworker/0:3+events_freezable
 6087 root      20   0  251124   9596   8608 S  25.0   0.0   0:08.02 boltd
 1159 root      20   0       0      0      0 I  18.8   0.0   0:12.23 kworker/10:2-events

I can only assume the USB controller built into the CPU is a root hub with attached devices that are crital for the system’s stability. Alternatively, I’m missing something really obvious. Any insight into what’s actually going on is greatly appreciated.