Ram Memory PCI device in IOMMU groups
So, lately I've been toying around with vfio passthrough on my laptop; here are it's IOMMU groups:
IOMMU Group 0: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 4-core Processor Host Bridge/DRAM Registers [Coffee Lake H] [8086:3e10] (rev 07)
IOMMU Group 1: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116M [GeForce GTX 1660 Ti Mobile] [10de:2191] (rev a1)
IOMMU Group 10: 00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 [8086:a330] (rev f0)
IOMMU Group 11: 00:1d.5 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #14 [8086:a335] (rev f0)
IOMMU Group 12: 00:1e.0 Communication controller [0780]: Intel Corporation Device [8086:a328] (rev 10)
IOMMU Group 13: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:a30d] (rev 10) 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS [8086:a348] (rev 10) 00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] (rev 10) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] (rev 10)
IOMMU Group 14: 06:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808]
IOMMU Group 15: 07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
IOMMU Group 2: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 (Mobile) [8086:3e9b]
IOMMU Group 3: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 07)
IOMMU Group 4: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model [8086:1911]
IOMMU Group 5: 00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Lake PCH Thermal Controller [8086:a379] (rev 10)
IOMMU Group 6: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10) 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] (rev 10) 00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560 [Jefferson Peak] [8086:a370] (rev 10)
IOMMU Group 7: 00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0 [8086:a368] (rev 10) 00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #1 [8086:a369] (rev 10)
IOMMU Group 8: 00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] (rev 10)
IOMMU Group 9: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller [8086:a353] (rev 10)
I've already succeeded in passing the integrated graphics in legacy mode, but now I'm wondering whether it was possible to also passing through the USB controller.
As you can see it is in a shared group with the WiFi card and a misterious RAM memory device.
Now, if I where to using the infamous ACS patch, would I also have to passthrough that RAM device? Is it even possible?
Thanks.
EDIT: Well, it appears that acs override does not separate the usb controller from the RAM device, even when using pcie_acs_override=downstream,multifunction (which is effectively the same as using multifunction only because pretty much every distinct device already had its own IOMMU group.
EDIT2: Just wanted you guys to know that it works wonderfully, even Bluetooth is recognized and works under Macos. Ultimatwly, the ACS patch only separated the WiFi card from the other 2 devices of the group, but I just passed both the USB controller and that ram device to the VM and it started working right away, yay!
Posted Nov 27, 2019, 12:52 PM UTC · edited
Well you can try. Most likely the USB controller will be the controller built-into the chipset. Do you know what devices are connected to the USB controller already? Because usually also PC internal components are likely to connected with that USB controller already: Touchpad, SD-card reader, internal switches etc.
In general, with limited usb controllers it might not be really worth it to pass-through the whole controller with vfio in order to get a single USB device to the guest.
EDIT: To answer the question: Only pass-through the USB controller.
So aside from the root hubs (which I would guess are not actual devices) I have the keyboard (048d:c100), the webcam (5986:2113), and this usb bluetooth device (8087:0aaa) which I don't understand (shouldn't bluetooth be handled by the Intel Wireless AC 9560?).
Honestly I'd be fine passing them all.
The reason I'm pushing for a brute force passthrough of the usb controller is because I'm trying to make a virtual hackintosh that's as close to bare metal as possible, and I recently found out that Catalina does not have drivers for whathever qemu-xhci emulates (nor for nec-usb-xhci).
So because I'm stuck with i440fx because of the legacy igd passthrough, that leaves me with the default usb bus which is just usb 1. (which works, btw, but even on a Fedora guest makes the mouse lag pretty bad, even).
I also tried evdev passthrough, but that only works for keyboard for me, the mouse event only seems to trigger button presses on the guest.
Anyway, thank you, I'm definitely trying this out.