YouAreTheOneNeo Posted July 4, 2017 Share Posted July 4, 2017 (edited) All, I attempted to follow these guides: https://forums.lime-technology.com/topic/35112-guide-passthrough-entire-pci-usb-controller/ https://www.reddit.com/r/unRAID/comments/5irsa9/video_guide_how_to_easily_pass_through_a_usb/ I'm having issues with my particular hardware. I'd also like to apologise for the density of this post! The output of lspci is as follows: root@UnRaid:~# lspci | grep USB 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 0c:00.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) 0c:00.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) 0c:00.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) I'm trying to pass through the NEC controller(s). Oddly, the two controllers 0c:00.0 and 0c:00.1 share the same ID: root@UnRaid:~# lspci -nnvv | grep NEC 0c:00.0 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 43) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Controller [1033:0035] 0c:00.1 USB controller [0c03]: NEC Corporation OHCI USB Controller [1033:0035] (rev 43) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Controller [1033:0035] 0c:00.2 USB controller [0c03]: NEC Corporation uPD72010x USB 2.0 Controller [1033:00e0] (rev 04) (prog-if 20 [EHCI]) Subsystem: NEC Corporation uPD72010x USB 2.0 Controller [1033:00e0] The IOMMU group for these also contains the PCI bridge, but I read somewhere (I can't remember exactly where) that this doesn't usually matter: IOMMU group 16 [8086:244e] 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) [1033:0035] 0c:00.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) [1033:0035] 0c:00.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) [1033:00e0] 0c:00.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) I blacklisted the three USB controllers in the syslinux configuration (attempted using both vfio-pci.ids and pci-stub.ids), and the controllers then appeared under "Other PCI Devices" in the VM. After adding them, and updating the config, I get the following error when the VM is launched: internal error: qemu unexpectedly closed the monitor: 2017-07-04T09:07:17.805585Z qemu-system-x86_64: -device vfio-pci,host=0c:00.0,id=hostdev2,bus=pci.0,addr=0x8: vfio: Error: Failed to setup INTx fd: Device or resource busy 2017-07-04T09:07:17.841241Z qemu-system-x86_64: -device vfio-pci,host=0c:00.0,id=hostdev2,bus=pci.0,addr=0x8: Device initialization failed I'm the exact opposite of an expert, so to me that is gibberish; however, after trawling the forums and google, I came across this thread on the ubuntu forums: https://ubuntuforums.org/showthread.php?t=2299835 In it, there it is mentioned that the PCIe card (I'm using plain old PCI) doesn't support PCI2.3 INTx disable, and thus requires an entire interrupt line to itself, which can be achieved by dropping anything that shares the interrupt line from it's driver by echoing a 1 into it's remove parameter. After further googling, I have seen that switching slots on the motherboard can change which interrupts are used. Unfortunately, I only have one PCI slot on the motherboard, and I had intended to use the PCIe x4 slot for a PCIe to M.2 adapter, to put in an NVMe SSD and pass it through to a windows guest. I have other, full sized, PCIe slots, but I had intended to use those for GPUs. Further output from lspci indicates that the three USB controllers are using three IRQ lines: root@UnRaid:~# lspci -v -s 0c:00.* 0c:00.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Controller Flags: medium devsel, IRQ 16, NUMA node 0 Memory at df602000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [40] Power Management version 2 Kernel driver in use: vfio-pci 0c:00.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Controller Flags: medium devsel, IRQ 17, NUMA node 0 Memory at df601000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Kernel driver in use: vfio-pci 0c:00.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) (prog-if 20 [EHCI]) Subsystem: NEC Corporation uPD72010x USB 2.0 Controller Flags: medium devsel, IRQ 18, NUMA node 0 Memory at df600000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Kernel driver in use: vfio-pci and the output from the INTx check script indicates that my PCI card does indeed not support INTx Disable: root@UnRaid:~# /mnt/user/Downloads/intx_check.sh 0c:00.0 INTx disable support NOT available on 0c:00.0 I can't figure out how to interpret the output of cat /proc/interrupts to find out which other devices are using the same IRQ lines as these controllers, and whether or not it's actually viable to drop the shared devices from their driver. I apologise at how long this is: root@UnRaid:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31 0: 139 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 2-edge timer 1: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 1-edge i8042 8: 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0 9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi 12: 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 12-edge i8042 16: 196428 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 16-fasteoi ehci_hcd:usb1 18: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 18-fasteoi i801_smbus 23: 118 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 23-fasteoi ehci_hcd:usb2 25: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 16384-edge aerdrv, PCIe PME 26: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 18432-edge aerdrv, PCIe PME 28: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 32768-edge aerdrv, PCIe PME 30: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 49152-edge aerdrv, PCIe PME 31: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 278528-edge aerdrv, PCIe PME 32: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 458752-edge PCIe PME 33: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 460800-edge PCIe PME 34: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 464896-edge PCIe PME 35: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 466944-edge PCIe PME 36: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 473088-edge PCIe PME 38: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 67141632-edge aerdrv, PCIe PME 40: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 67158016-edge aerdrv, PCIe PME 41: 538561 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 512000-edge ahci[0000:00:1f.2] 42: 544928 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 3670016-edge eth0-rx-0 43: 306504 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 3670017-edge eth0-tx-0 44: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 3670018-edge eth0 45: 213244 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 2621440-edge isci-msix 46: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 2621441-edge isci-msix 47: 32569 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 5767168-edge eth1-rx-0 48: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 5767169-edge eth1-tx-0 49: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 5767170-edge eth1 50: 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 5242880-edge ahci[0000:0a:00.0] 72: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 DMAR-MSI 0-edge dmar0 73: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 DMAR-MSI 1-edge dmar1 NMI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Non-maskable interrupts LOC: 3826188 2874305 2830163 2960436 2057691 1954701 1942347 1913162 1338836 1373719 1368412 1444601 1327281 1486811 1357234 1404403 1971863 2946981 2917786 2944396 1760475 1858298 1830511 1824985 1342180 1181314 1353681 1296533 1245308 1322828 1310406 1220719 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Performance monitoring interrupts IWI: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 APIC ICR read retries RES: 420049 101399 29767 11440 6423 4132 3169 2871 4450 2663 2761 6610 2510 3404 2427 2576 2420 3244 3149 2814 2317 2341 2261 2827 2502 2156 2635 2391 2411 2288 2386 2430 Rescheduling interrupts CAL: 3509 4387 4313 4689 3977 3819 3324 2999 27663 20874 53354 29626 6826 6654 5872 16614 3204 3044 3066 2867 3089 3207 2964 3013 7043 5967 9490 6675 14728 50251 35245 18269 Function call interrupts TLB: 2886 3755 3673 4041 3331 3181 2680 2349 2249 1987 2543 1836 2045 2220 2131 1884 2601 2417 2431 2227 2452 2587 2491 2389 2104 2731 2201 2436 2338 2221 2003 2436 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 Machine check polls ERR: 0 MIS: 0 PIN: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt notification event PIW: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt wakeup event root@UnRaid:~# I also attempted to blacklist the PCI bridge itself, and pass that through to the guest using the <hostdev> tags, but I got more strange errors that seemed worse than the one above, and it didn't seem like a very good idea to me anyway. Does PCI even support PCI2.3 INTx Disable, or is that a feature of the newer PCIe bus only? Furthermore, given that I can't move the PCI card to another slot, because it is the only one, is it worth buying different hardware? I've seen another USB expansion card that uses a VIA chipset instead of a NEC one; what are the chances that it will support PCI2.3 INTx Disable? If all of this doesn't work, then are there any workarounds, or am I screwed? If you got this far, then thanks for reading! PJ Update: I picked up the new PCI card with the VIA chipset. I will update once I am home and able to fit it. Update 2: Fitted the new VIA chipset card. Running the INTx Disable Check script results in the card not supporting that feature either. I'm starting to think that it's a limitation of the older PCI bus. Edited July 6, 2017 by YouAreTheOneNeo Update Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.