Передача USB-контролера, яка дійсно залишається стабільною (IOMMU + перенаправлення переривань)

February 28, 2026 • February 28, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви передали цілий USB-контролер, бо втомилися від того, що «передача окремого USB-пристрою» відвалюється щоразу, коли пристрій здригається.
Все працює день. Потім віртуальна машина втрачає клавіатуру, донгл зникає або на хості з’являється шквал скидань, ніби хтось виганяє демонів.

Стабільна передача USB-контролера — це не удача. Це про правильну роботу IOMMU, перенаправлення переривань,
чисту ізоляцію і відмову від хитрувань у невідповідних місцях. Зробимо це нудним — а значить надійним.

Що насправді означає «стабільно» для передачі USB

«Стабільно» — це не «воно запустилося одного разу». Стабільно означає:

Жодних несподіваних відключень під час реенумерації пристрою (часто трапляється з аудіоінтерфейсами, рідер-ключами, SDR, HID-донглами).
Жодних зависань хоста, коли гість скидає контролер або пристрій веде себе неправильно.
Передбачувана латентність без періодичних затримок через хвилі переривань або конфлікти з драйвером хоста.
Відновлюваність при переході в режим сну/пробудження та перезавантаженнях гостя без залишення контролера заблокованим до перезавантаження хоста.
Чисте володіння: або хост володіє контролером, або гість володіє ним. Не «іноді так, іноді сяк».

Передача USB-контролера — це «передача PCIe-пристрою з додатковими способами відмови». Контролери скидаються, ендпоїнти переговорюють швидкості,
хаби брешуть, а дешеві кристали інтерпретують специфікацію творчо. Якщо ставитися до USB-passthrough як до галочки,
отримаєте надійність «галочка».

Жарт #1: USB означає «Usually Sorta Behaves» — тобто «Зазвичай Ніби Працює» — поки ви не почнете віртуалізувати.

Цікаві факти та історія, які стануть в нагоді

USB 1.1 використовував контролери OHCI/UHCI; USB 2.0 стандартизував EHCI плюс супутні контролери для low/full-speed пристроїв.
xHCI (USB 3.x) уніфікував безлад: один модель контролера для low/full/high/super speed. Добре для ОС, але шляхи скидання і енергоменеджменту стали складнішими.
Перенаправлення переривань стало обов’язковим, коли ми почали давати VM прямий доступ до пристроїв; без нього пристрій може вводити переривання небезпечним чином.
VT-d (Intel) та AMD-Vi (AMD IOMMU) вирішують ізоляцію DMA, але ранні покоління мали проблеми з ATS/PRI і маршрутизацією переривань.
MSI/MSI-X здебільшого замінили старі INTx для сучасних PCIe-пристроїв; це добре для passthrough, але лише якщо перенаправлення працює коректно.
ACS (Access Control Services) на PCIe-комутаторах/кореневих портах впливає на розподіл IOMMU-груп; споживчі платформи часто економлять тут.
USB-контролери можуть ділитися кристалом з іншими функціями (SATA, Ethernet, аудіо), створюючи неприємні багатофункціональні IOMMU-групи, які опираються чистій передачі.
«Передача окремого USB-пристрою» і «передача USB-контролера» — різні світи: перше — це емулювання/проксі, друге — реальне володіння апаратурою.

Справжня архітектура: IOMMU, DMA, переривання і чому USB особливий

Передача USB-контролера — це історія про DMA і переривання

Коли ви передаєте PCIe USB-контролер (xHCI/EHCI), ви віддаєте пристрій з підтримкою DMA гостю. Драйвер гостя
програмує контролер фізичними адресами (гостьові «фізичні», які перекладає гіпервізор/IOMMU), і контролер
DMA-є дані прямо в пам’ять гостя. У цьому весь сенс: прибрати хост із шляху даних.

Це працює, коли виконуються дві речі:

Ізоляція DMA правильна. Контролер повинен звертатися лише до пам’яті гостя, а не хоста, і переклади не повинні давати помилки під навантаженням.
Доставка переривань правильна. Переривання контролера мають доходити до гостя надійно, без «залипання», неправильного маршруту або викликати хвилі на хості.

Де на практиці це ламається

Нестабільність зазвичай виникає через одну (або комбінацію) з цих причин:

Відсутнє перенаправлення переривань (або воно відключене/з дефектом), що призводить до небезпечної або ненадійної доставки MSI в сценаріях passthrough.
Забруднення IOMMU-групи: контролер ділить групу з чимось, що хост повинен залишити за собою (або чого гість не повинен отримати).
Енергоменеджмент: ASPM, runtime PM і USB autosuspend погано взаємодіють з passthrough, особливо на споживчих платах.
Семантика скидання: деякі xHCI-контролери не скидаються чисто через FLR і можуть зависати до повного циклу живлення.
Кернел-кавірки та володіння драйвером: хост захоплює контролер рано (xhci_hcd), а потім VFIO намагається прив’язати його пізніше; результати варіюються від вдалих до нестабільних.
Налаштування прошивки/BIOS: IOMMU увімкнено, але «перенаправлення переривань» вимкнено; або «Above 4G decoding» вимкнено; або таблиці маршрутизації PCIe ушкоджені.

До чого варто прагнути

Стабільна конфігурація має такі властивості:

USB-контролер знаходиться сам у своїй IOMMU-групі (або згрупований тільки з нешкідливими сусідами, які ви можете передати разом).
Хост ніколи не завантажує свій звичайний драйвер для цього контролера; VFIO володіє ним з раннього завантаження.
IOMMU увімкнено і працює в режимі, який підтримує переклади DMA на масштабі (без відкатів).
Перенаправлення переривань увімкнено і підтверджено в логах ядра.
Використовується MSI/MSI-X (сучасні контролери), а застарілий INTx уникається, якщо ви не знаєте, навіщо він вам.

Корисна перефразована ідея, яку люди з експлуатації вчаться важко:
перефразовано: «Сподівання — це не стратегія.» — часто приписують кільком лідерам надійності; суть від цього не змінюється.

Перенаправлення переривань: тихий герой

Перенаправлення переривань — те, що багато гайдiв трактують як опціональний гарнір. Це не опція, коли вам потрібна стабільність.
У світі VFIO «іноді працює» без нього, поки ви не розширите кількість переривань, не наситите I/O або не натрапите на крайовий випадок пристрою/прошивки.

Що насправді робить перенаправлення переривань

У PCIe пристрої зазвичай використовують MSI/MSI-X переривання: записи на конкретну пару адреса/дані, які платформа інтерпретує як переривання.
Без перенаправлення ці записи можуть бути погано обмежені. З перенаправленням IOMMU/перенаправник переривань забезпечує шар трансляції, щоб
гіпервізор міг безпечно й надійно маршрутизувати переривання пристрою до відповідного вектору/CPU гостя.

Режими відмов, які ви побачите, коли перенаправлення відсутнє або не працює

Випадкові відключення пристроїв при зміні навантаження (тріск аудіо, лаги HID, скидання донглів).
Підвішування в гості, коли пристрій живий, але переривання перестають надходити й драйвер таймаутить.
dmesg хоста показує помилки IOMMU або симптоми типу «IRQ stuck».
VFIO відмовляється запускати VM з попередженнями про небезпечні переривання, залежно від налаштувань ядра.

Висновок: якщо ваша платформа неправильно реалізує перенаправлення переривань, перестаньте намагатися її перекручувати. Поміняйте платформу або ізолюйте навантаження.
Це зекономить вам більше грошей, ніж ваш час у сумі.

Апаратні вибори, що вирішують вашу долю

Вибирайте контролери, відомі своєю поведінкою

Якщо ви можете обирати USB-контролер, візьміть той, що має репутацію чистого скидання і стабільної доставки MSI.
На практиці дискретні PCIe USB-карти часто простіші в роботі, ніж інтегровані контролери, бо:
вони частіше потрапляють у власну IOMMU-групу і рідше ділять лінії/функції.

Також: уникайте передачі єдиного контролера платформи, якщо хост потребує його для аварійного доступу до консолі.
Забезпечте хост «нудним» USB-шляхом (навіть базовим USB2 контролером) і передайте окремий xHCI-контролер для VM.

Фірмове ПЗ материнської плати важливіше, ніж хочеться

Дві плати з тим самим чіпсетом можуть поводитися зовсім по-різному через налаштування BIOS і якість ACPI/PCIe таблиць від вендора.
Зверніть увагу на:

Intel VT-d / AMD IOMMU увімкнено.
Перенаправлення переривань увімкнено (іноді називають «IRQ remapping» або об’єднують під VT-d).
Above 4G decoding увімкнено на системах з великою кількістю PCIe-пристроїв.
SR-IOV налаштування безпосередньо не стосується USB, але плати, що його показують, зазвичай не «іграшкові».
CSM/Legacy boot вимкнено, якщо можливо; тільки UEFI зазвичай чистіше для сучасної віртуалізації.

Не «розв’язуйте ACS override» проблему фізики, якщо не доводиться

ACS override може розділити IOMMU-групи в програмному забезпеченні, прикидаючись, що ACS-функції існують там, де їх немає.
Це спокусливо. Але також збільшує радіус ураження, якщо пристрій почне вести себе неправильно, бо ізоляція стає умовною.
Якщо це система схожа на продакшн, уникайте ACS override, поки ви не прийняли ризик і не можете терпіти наслідки.

Жарт #2: Включення ACS override, щоб «виправити» групи, — це як написати на картонній скриньці «вогнетривка» і назвати її сейфом.

Практичні завдання: команди, очікувані результати та рішення

Це ті завдання, які я реально виконую, коли хтось каже: «USB passthrough нестабільний». Кожне завдання містить:
команду, що означає її вивід, і рішення, яке з цього випливає.

Завдання 1: Підтвердити, що IOMMU увімкнено в рядку команд ядра

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0 root=UUID=... ro quiet intel_iommu=on iommu=pt

Значення: Ви хочете бачити intel_iommu=on (Intel) або amd_iommu=on (AMD).
iommu=pt часто використовується, щоб зменшити накладні витрати для хост-пристроїв, застосовуючи passthrough-мапи.

Рішення: Якщо прапори IOMMU відсутні, додайте їх у завантажувач і перезавантажтеся. Без IOMMU — немає довіреної передачі.

Завдання 2: Перевірити, що IOMMU дійсно ініціалізувався (не довіряйте лише cmdline)

cr0x@server:~$ dmesg | egrep -i 'iommu|vt-d|amd-vi|dmari' | head -n 30
[    0.000000] Command line: ... intel_iommu=on iommu=pt
[    0.112233] DMAR: IOMMU enabled
[    0.112240] DMAR: Interrupt remapping enabled
[    0.112250] DMAR: x2apic is enabled

Значення: Ключова лінія — «IOMMU enabled» і «Interrupt remapping enabled.» На AMD ви побачите повідомлення AMD-Vi/IOMMU.

Рішення: Якщо ви не бачите перенаправлення переривань увімкненим, зайдіть у BIOS/UEFI і виправте це. Якщо платформа не може — сприймайте це як критичну перешкоду для стабільності.

Завдання 3: Перевірити наявність попереджень «no interrupt remapping» або «unsafe interrupts»

cr0x@server:~$ dmesg | egrep -i 'remapping|unsafe|vfio|irq' | tail -n 40
[    1.234567] DMAR: No interrupt remapping support. Use 'intremap=off' to disable interrupt remapping.
[    8.765432] vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x19@0x168

Значення: «No interrupt remapping support» — червоний прапор. Рядок про VFIO — звичайний шум.

Рішення: Якщо платформа не підтримує перенаправлення, іноді можна тимчасово миритися, але слід очікувати дивних проблем. Для продакшн — міняйте обладнання.

Завдання 4: Визначити PCI-адресу USB-контролера та vendor/device ID

cr0x@server:~$ lspci -nn | egrep -i 'usb|xhci|ehci'
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
00:14.0 USB controller [0c03]: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller [8086:a2af]

Значення: Тепер у вас є BDF (03:00.0) і ID (1b21:2142).

Рішення: Віддавайте перевагу передачі дискретного контролера (тут 03:00.0) замість інтегрованого в чіпсет (00:14.0).

Завдання 5: Перевірити ізоляцію IOMMU-груп

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; ls -l "$g/devices"; done | sed -n '1,40p'
Group 13
total 0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:03:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:03:00.0
Group 7
total 0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:00:14.2 -> ../../../../devices/pci0000:00/0000:00:14.2

Значення: Група 13 містить лише 03:00.0 — добре. Група 7 містить 00:14.0 і 00:14.2 — спільні функції.

Рішення: Передавайте пристрої, які ізольовані, або передавайте всю групу разом. Не вирізайте одну функцію з багатофункціональної групи хірургічно.

Завдання 6: Подивитися, який драйвер зараз володіє контролером

cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
        Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_pci

Значення: Хост-драйвер (xhci_hcd) зараз володіє ним. Це не те, що нам потрібно для passthrough.

Рішення: Прив’яжіть цей пристрій до vfio-pci рано, перш ніж xHCI його захопить, або обережно відв’яжіть/перев’яжіть під час виконання.

Завдання 7: Прив’язати контролер до vfio-pci (метод під час роботи)

cr0x@server:~$ sudo modprobe vfio-pci
cr0x@server:~$ echo 0000:03:00.0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/driver/unbind
0000:03:00.0
cr0x@server:~$ echo 1b21 2142 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
1b21 2142

Значення: Ми відв’язали від поточного драйвера і сказали vfio-pci забрати цей vendor/device ID.

Рішення: Якщо пристрій відмовляється відв’язатися, можливо, хост його використовує (root filesystem на USB, клавіатура консолі і т.д.). Усуньте залежність спершу.

Завдання 8: Підтвердити, що vfio-pci тепер використовується

cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
        Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
        Kernel driver in use: vfio-pci
        Kernel modules: xhci_pci

Значення: Вірно. Хост більше не керує ним.

Рішення: Продовжуйте підключати його до VM. Якщо після перезавантаження він повертається до xHCI, налаштуйте постійне прив’язування.

Завдання 9: Зробити прив’язування vfio-pci постійним через конфіг модулів

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=1b21:2142 disable_vga=1
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0

Значення: Initramfs тепер включатиме прив’язування, щоб vfio-pci хапав контролер рано.

Рішення: Перезавантажтеся і підтвердіть, що володіння драйвером лишається vfio-pci. Раннє прив’язування запобігає гонкам при завантаженні і дивним «працює, якщо…» випадкам.

Завдання 10: Підтвердити режим переривань (MSI/MSI-X) для переданого контролера

cr0x@server:~$ cat /proc/interrupts | egrep -i 'xhci|03:00.0' || true
  45:          0          0          0          0  IR-PCI-MSI 65536-edge      xhci_hcd:usb3

Значення: Поки контролер належить хосту, він використовує «IR-PCI-MSI» (перенаправлене MSI). Після прив’язки до vfio-pci він має зникнути з переривань хоста.

Рішення: Якщо ви бачите лише старі INTx-рядки або немає «IR-» на платформах, що повинні це підтримувати, підозрюйте відсутнє перенаправлення або дивну прошивку.

Завдання 11: Перевірити здоров’я VFIO/IOMMU-мап під навантаженням (шукати faults)

cr0x@server:~$ sudo dmesg -w
[  412.123456] vfio-pci 0000:03:00.0: enabling device (0000 -> 0002)
[  418.654321] DMAR: DRHD: handling fault status reg 2
[  418.654330] DMAR: [DMA Read NO_PASID] Request device [03:00.0] fault addr 0x12345000 [fault reason 0x05] PTE Read access is not set

Значення: Помилка DMA. Це не «нешкідливо». Контролер спробував виконати DMA туди, куди IOMMU не зробив мапу.

Рішення: Якщо помилки з’являються тільки під навантаженням, підозрюйте брак у залізі, особливість платформи IOMMU або драйвер гостя, що робить щось, чого контролер/прошивка не очікують.
Спробуйте інший контролер, оновіть BIOS, оновіть ядро та відключіть підозрілі функції PCIe (див. пізніші завдання).

Завдання 12: Перевірити на наявність AER (PCIe Advanced Error Reporting) виводу

cr0x@server:~$ dmesg | egrep -i 'aer|pcie.*error|corrected error' | tail -n 20
[  987.111222] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
[  987.111240] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[  987.111260] pcieport 0000:00:01.0:   device [8086:1901] error status/mask=00000001/00002000

Значення: Corrected errors не смертельні відразу, але вони дивно добре корелюють з випадковими скиданнями і подіями «USB зник».

Рішення: Пересуньте карту, змініть слот, примусьте Gen3 замість «Auto», відключіть агресивний ASPM або замініть сумнівне обладнання.

Завдання 13: Проінспектувати налаштування енергоменеджменту, що часто ламають передачу USB

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
default

Значення: ASPM у «default». На деяких платформах це працює. Інші вигадують нові режими відмов.

Рішення: Якщо ви бачите фліпання лінку або AER навколо переданого контролера, спробуйте завантажитися з pcie_aspm=off як тест.
Якщо стабільність покращиться — знайшли баг енергоменеджменту, а не віртуалізації.

Завдання 14: Підтвердити, що VM бачить контролер і використовує реальний драйвер

cr0x@server:~$ sudo virsh domiflist win11
 Interface  Type       Source     Model       MAC
-------------------------------------------------------
 vnet0       bridge     br0        virtio      52:54:00:aa:bb:cc

cr0x@server:~$ sudo virsh dumpxml win11 | egrep -n 'hostdev|03:00.0' -n
132:    
136:      
137:        
138:      
139:

Значення: Конфіг VM містить переданий пристрій.

Рішення: Якщо гість не може встановити/використати xHCI-контролер, можливо, бракує налаштувань UEFI або пристрій не дійсно прив’язаний до vfio-pci на хості.

Завдання 15: Перевірити проблеми зі скиданням (FLR/D3cold) після перезавантаження гостя

cr0x@server:~$ sudo dmesg | egrep -i 'reset|flr|D3cold|vfio-pci 0000:03:00.0' | tail -n 30
[ 1322.333444] vfio-pci 0000:03:00.0: not ready 1023ms after FLR; waiting
[ 1323.444555] vfio-pci 0000:03:00.0: not ready 2047ms after FLR; giving up

Значення: Пристрій не повернувся після скидання чисто. Класична проблема «працює, поки ви не перезавантажите VM».

Рішення: Спробуйте іншу модель USB-контролера, змініть слот і вимкніть runtime енергозбереження PCIe. Деякі контролери просто не скидаються надійно в контексті passthrough.

Завдання 16: Підтвердити режим IOMMU і тип домену (компроміс продуктивність ↔ безпека)

cr0x@server:~$ sudo dmesg | egrep -i 'iommu.*domain|Default domain' | head -n 20
[    0.113000] DMAR: Default domain type: Passthrough (set via iommu=pt)

Значення: Хост використовує passthrough-мапи за замовчуванням; VFIO-пристрої все одно отримують ізольовані домени.

Рішення: Якщо ви налагоджуєте дивні DMA-помилки, тимчасово приберіть iommu=pt, щоб перевірити, чи змінить це поведінку. Це діагностичний важіль, а не постійне рішення.

Швидкий план діагностики (перевірити спочатку/потім/пізніше)

Коли передача USB-контролера ненадійна, ви хочете швидко знайти вузьке місце: можливості платформи, ізоляція, поведінка скидання
або щось нудне, як проблемний слот.

Спочатку: «Чи може ця платформа робити безпечні переривання?»

Перевірте dmesg на наявність «Interrupt remapping enabled.» Якщо його немає, не витрачайте тиждень на тонке налаштування.
Подивіться, чи використовує контролер MSI/MSI-X під власністю драйвера хоста (перед тим, як VFIO його забере). Якщо ви застрягли на legacy INTx, очікуйте проблем.
Шукайте попередження VFIO про небезпечні переривання.

Потім: «Чи справжня ізоляція, чи я борюся з фізикою IOMMU-груп?»

Перелічіть IOMMU-групи. Якщо USB-контролер приклеєний до інших пристроїв, які ви не можете передати, варіанти: інший слот, інший контролер, інша материнська плата.
Уникайте ACS override як першого рішення. Використовуйте його тільки коли ризик прийнятний і ви можете повністю протестувати.

Пізніше: «Чи скидається він чисто?»

Перезавантажте гостя кілька разів і дивіться на таймаути FLR, повідомлення «device not ready» або зникнення контролера з PCI конфіг-простору.
Якщо він зависає після одного перезавантаження гостя — це часто поведінка кристалу/прошивки контролера. Поміняйте контролер, перш ніж переписувати стек.

Четверте: «Чи це замаскована проблема лінку/живлення?»

Шукайте AER corrected errors навколо кореневого порту контролера.
Тестуйте з вимкненим ASPM і фіксованим поколінням PCIe (Gen3/Gen4) замість Auto.
Пересуньте карту в інший слот і перевірте знову. Так, серйозно. Слоти можуть бути хиткими, біфуркація може бути дивною, і кореневий порт має значення.

П’яте: «Чи навантаження викликає реальний крайовий випадок USB?»

Аудіоінтерфейси: слідкуйте за isochronous трансферами і періодичною поведінкою типу XRUN. Це часто доставка переривань або планування.
HID-донгли: шукайте короткі просадки живлення або цикли реенумерації; це часто викликано енергоменеджментом і скиданнями.
Високошвидкісне зберігання: перевірте, чи контролер ділить лінії або не тротує; USB3 зберігання може створювати жорстокі шаблони переривань.

Три корпоративні історії з поля бою

1) Інцидент через неправильне припущення: «IOMMU увімкнено, отже ми в безпеці»

Середня компанія запускала Windows VM для кількох апаратно-прив’язаних робочих процесів: ліцензійні донгли, вимірювальні пристрої, рідер-ключ.
Вони вже зрозуміли, що передача окремих USB-пристроїв ненадійна, тому стандартизувалися на передачі виділеного USB-контролера.
Розгортання виглядало чистим у лабораторії. Потім користувачі в продакшні стали повідомляти, що донгл «випадає» кожні кілька годин.

Команда віртуалізації робила те, що роблять команди: звинувачували Windows, QEMU, космічні промені. Вони міняли донгли. Міняли хаби.
Вони навіть пінували CPU гостя. Проблема тривала і мала неприємну закономірність: траплялася частіше під час пікового навантаження, коли хости
були зайняті і VM мала більше переривань.

Неправильне припущення було тонким: вони підтвердили intel_iommu=on і бачили DMAR логи, тому вважали платформу «IOMMU здатна».
Але вони не перевірили перенаправлення переривань. В BIOS VT-d було увімкнено, але окремий тумблер «Interrupt Remapping» після оновлення прошивки був вимкнений за замовчуванням.
Ядро ввічливо про це повідомляло, але ніхто не шукав саме ту лінію.

Після увімкнення перенаправлення переривань загадкові відключення зникли. Виправлення здалося антиклімактичним, що часто буває з хорошими фіксами.
Основний висновок постмортему: «IOMMU увімкнено» — це не бінарна ознака. DMA-трансляція і перенаправлення переривань — різні ніжки стільця.
Заберіть одну — і ви стоїте на вібраціях.

2) Оптимізація, що відкинула назад: «Збережемо слот і поділимо інтегрований контролер»

Інша організація стандартизувала компактні сервери з обмеженою кількістю PCIe-слотів. Хтось запропонував оптимізацію:
замість придбання виділеної USB-карти на хост вони передаватимуть інтегрований xHCI-контролер і залишать мінімальні потреби хоста.
На папері це економило слоти і зменшувало витрати. На практиці це зробило хост крихким.

Інтегрований контролер був в IOMMU-групі з іншою платформною функцією. Іноді це була супутня функція, іноді — підсистема чіпсету, потрібна для стабільної роботи хоста.
Вони примусили ситуацію трюками розділення груп. Це працювало — поки не перестало.
Перезавантаження гостя спричинило скидання контролера так, що хост помітив це у невдалий момент, і раптом хост втратив свою єдину локальну USB-клавіатуру
і кілька внутрішніх пристроїв. Потрібні були люди на місці. Операційна команда не була в захваті.

Наступна спроба «оптимізувати» переривання і енергоспоживання: увімкнення глибших C-станів і агресивного ASPM, бо системи «здебільшого бездіяльні».
Це зробило проблему інтермітуючою і тому дорожчою у виправленні. VM була стабільною вдень, неквапливою вночі, а логи виглядали невинно.
Зрештою AER логи і зміни стану лінку пов’язали нестабільність з енергоменеджментом, що взаємодіє зі шляхом скидання контролера.

Вони відкотили оптимізацію: виділені USB-карти, хост зберігає інтегрований USB, консервативні налаштування живлення PCIe.
Це коштувало більше. Але також прибрало цілу категорію відмов. Ось така ROI, про яку ніхто не хвалиться у презентаціях, але яку всі цінують о 3 ранку.

3) Нудна але правильна практика, що врятувала день: «Передпольотна валідація та відомий запасний шлях»

Команда фінансових сервісів мала політику, що здалася надто обережною: кожен новий хост повинен пройти «перевірку passthrough» перед входом у віртуалізаційний кластер.
Вона включала перевірку перенаправлення переривань, перевірку IOMMU-груп, запуск циклу перезавантажень гостя
та навмисне хотплаг/анплаг пристроїв за переданим контролером з одночасним збором логів.

Під час одного циклу закупівлі вони отримали партію серверів з трохи іншим ревізією материнської плати. Специфікація виглядала однаково.
Екрани BIOS були майже такі ж. Але IOMMU-групи були іншими: інтегрований USB-контролер тепер групувався з іншим пристроєм
через зміну маршрутизації. Попереднє покоління мало чисту ізоляцію; це — ні.

Оскільки валідація була обов’язкова, проблему виявили до того, як сервери пішли у продакшн.
Вони скоригували дизайн: хости використовували відому хорошу дискретну USB-карту для passthrough, а інтегрований контролер залишався за хостом.
«Нудна практика» тут не була героїкою — це було відмова прийняти «майже те саме залізо» як таке ж саме.

Найкраща частина: коли керівник поцікавився, чому дата запуску не зрушилася, чесна відповідь була «тому що ми зробили нудні тести, які завжди робимо».
Ніхто не аплодував. Системи працювали. Оце аплодисменти, які справді потрібні.

Типові помилки: симптом → корінь проблеми → виправлення

1) VM рандомно втрачає USB-пристрої за переданим контролером

Симптом: HID/аудіо/зберігання відключаються і підключаються; логи гостя показують скидання пристроїв; логи хоста здебільшого чисті.

Корінь: Перенаправлення переривань вимкнено або пошкоджено, що призводить до ненадійної доставки MSI під навантаженням.

Виправлення: Увімкніть перенаправлення переривань у BIOS/UEFI, підтвердіть у dmesg. Якщо не підтримується — змініть платформу.

2) Хост зависає або стає повільним, коли гість перезавантажується

Симптом: Перезавантаження гостя спричиняє зависання хоста; іноді лише I/O стагнує; іноді потрібен повний power cycle.

Корінь: Поведінка скидання контролера взаємодіє з драйвером хоста або чіпсетом; хост все ще володіє пов’язаними функціями або ресурси спільні в групі.

Виправлення: Переконайтеся, що vfio-pci прив’язаний рано; уникайте передачі пристрою в спільній IOMMU-групі; використовуйте дискретний контролер; оновіть BIOS.

3) VFIO відмовляється запускати VM або скаржиться на небезпечні переривання

Симптом: VM не запускається; помилки згадують мапування переривань або «no interrupt remapping support».

Корінь: Платформа не має або має відключене перенаправлення переривань; іноді налаштування ядра нав’язують безпеку.

Виправлення: Увімкніть перенаправлення; якщо неможливо — не використовуйте передачу контролера для цього робочого навантаження (або прийміть зменшену безпеку з відкритими очима).

4) Працює, поки ви не перезавантажите VM; потім контролер ніколи не повертається

Симптом: Перший запуск добре; після перезавантаження гостя наступний старт не вдається або пристрій відсутній; dmesg показує таймаути FLR.

Корінь: Контролер не може надійно виконати FLR; застряг у поганому енергетичному стані (D3cold) або баг прошивки.

Виправлення: Змініть модель контролера; спробуйте інший слот; відключіть runtime енергозбереження PCIe; іноді тільки перезавантаження хоста/повний цикл живлення вирішує проблему.

5) USB-аудіо потріскує або має періодичні пропуски у гості

Симптом: Аудіо клацає кожні кілька секунд; USB-інтерфейс залишається підключеним, але продуктивність жахлива.

Корінь: Латентність обробки переривань: планування vCPU, енергетичні стани CPU хоста, або проблеми з перенаправленням/афініті переривань.

Виправлення: Пінуйте vCPU, ізолюйте CPU хоста для затворних навантажень, уникайте глибоких C-станів і перевірте MSI з перенаправленням. Розгляньте виділений контролер на VM.

6) Контролер ділить IOMMU-групу з SATA/NIC/іншими критичними пристроями

Симптом: Ви не можете передати без втрати чогось, що потрібно хосту.

Корінь: Платформа не має ACS-сепарації; розташування плати з’єднує функції за одним upstream-портом.

Виправлення: Використайте інший PCIe-слот або дискретну карту; оберіть материнську плату з кращим розподілом IOMMU-груп; у продакшні уникайте ACS override.

7) Все виглядає правильно, але продуктивність нестабільна

Симптом: Пропускна здатність просідає; випадкові спайки латентності; іноді USB-зберігання зависає.

Корінь: Проблеми PCIe лінку (AER corrected errors), погані кабелі або проблеми з подачею живлення для високоспоживчих USB-пристроїв.

Виправлення: Перевірте AER-логи, відключіть ASPM, спробуйте підсилений хаб з чистим живленням, замініть PCIe-карту і не використовуйте фронтальні шлейфи для критичних пристроїв.

Контрольні списки / покроковий план

Покроково: побудувати стабільну конфігурацію передачі USB-контролера

Виберіть контролер: віддавайте перевагу дискретній PCIe xHCI-карті, що потрапляє у власну IOMMU-групу.
Налаштування прошивки: увімкніть VT-d/AMD IOMMU та перенаправлення переривань; увімкніть Above 4G decoding, якщо у вас багато PCIe-пристроїв.
Рядок ядра: встановіть intel_iommu=on або amd_iommu=on. За потреби iommu=pt після стабілізації.
Підтвердження в dmesg: підтвердіть, що IOMMU і перенаправлення переривань увімкнені. Якщо ні — зупиніться і виправте.
Перевірте IOMMU-групи: переконайтеся, що контролер можна ізолювати або передати цілою групою.
Прив’яжіть до vfio-pci рано: використовуйте /etc/modprobe.d/vfio.conf і перебудовуйте initramfs. Уникайте постійного перев’язування під час роботи як постійного рішення.
Підключіть до VM: використайте libvirt hostdev або еквівалент. Тримайте простоту: один контролер, одна VM, одне завдання.
Тест стабільності: цикл перезавантаження гостя, підключення/відключення пристроїв за контролером і тривале навантаження (копіювання USB-зберігання, аудіопотік тощо).
Слідкуйте за логами: перевіряйте DMAR/IOMMU помилки, AER-повідомлення та таймаути FLR.
Зафіксуйте енергетичні функції: якщо бачите помилки лінку або дивні скидання, відключіть ASPM і уникайте глибоких енергетичних станів. Потім протестуйте знову.

Операційний контрольний список: що зберегти після того, як усе працює

Запишіть BDF і vendor/device ID переданого пристрою у вашу систему управління конфігурацією.
Залиште хосту доступний USB-шлях для аварійного відновлення (віртуальне IPMI, виділений інтегрований USB або окремий контролер).
Після оновлень BIOS перевіряйте перенаправлення переривань і IOMMU-групи. Оновлення прошивки полюбляють «повертати до значень за замовчуванням».
Підтримуйте відому робочу версію ядра для VFIO-навантажень; оновлюйте цілеспрямовано з валідацією, а не «бо у вівторок».
Налаштуйте сповіщення про DMAR/IOMMU помилки та AER-шторм; це ранні попередження, а не дрібниці.

Питання та відповіді

Чи справді мені потрібне перенаправлення переривань для передачі USB-контролера?

Якщо ви хочете стабільності — так. Ізоляція DMA окремо не гарантує надійну доставку переривань. Без перенаправлення ви отримаєте «працює до навантаження»,
що витратить дні на діагностику.

Чому не просто передати окремі USB-пристрої замість контролера?

Бо передача окремого USB-пристрою зазвичай проксує USB-транзакції через хост. Це може підійти для миші.
Часто це погано для пристроїв, що скидаються, стрімлять isochronous аудіо або мають дивні ENUM-поведінки.
Передача контролера дає гостю реальне залізо і прибирає хост зі шляху даних.

Чи добре/погано `iommu=pt`?

Зазвичай це нормально і часто рекомендується для продуктивності хоста, бо незв’язані VFIO-пристрої отримують identity-мапи.
Для налагодження дивних трансляційних помилок тимчасово приберіть його, щоб побачити, чи зміниться поведінка. Не вважайте це магічним фіксом.

Мій USB-контролер у тій же IOMMU-групі, що й інші пристрої. Що робити?

Найкраща відповідь: змініть PCIe-слот, використайте іншу контролер-карту або материнську плату з кращим ACS/IOMMU-розподілом.
Передача частини групи — запит на нестабільність. ACS override може допомогти, але це торг за ризиком, а не безкоштовний обід.

Чому контролер зникає після перезавантаження гостя?

Через семантику скидання. Деякі контролери неправильно реалізують FLR, або застрягають у низькому енергетичному стані. Якщо ви бачите VFIO «not ready after FLR»,
перестаньте трактувати це як софтварну помилку і спробуйте інше залізо.

Чи варто вимикати ASPM і енергозбереження?

Якщо ви бачите AER-помилки, фліпання лінку або дивні скидання: так, як тест, а часто й як постійний вибір для latency-sensitive або passthrough-хостів.
Економія енергії приємна; стабільні переривання приємніші.

Чи можна безпечно передати чіпсетний (onboard) USB-контролер?

Іноді. Але це найбільш імовірно буде згруповано з іншими платформними функціями і найчастіше потрібне хосту.
Для надійної роботи дискретний контролер, виділений гостю — чистий дизайн.

У чому різниця між MSI і INTx для passthrough?

MSI/MSI-X — це повідомлення-базовані переривання і сучасний дефолт. INTx — це спадкові лінії переривань і можуть бути складнішими у віртуалізованих середовищах.
Загалом хочеться MSI/MSI-X з увімкненим перенаправленням переривань.

VM стартує, але в гості драйвер контролера показує помилки. Це проблема хоста?

Не завжди. Це може бути і проблема драйвера гостя, але почніть з перевірки dmesg хоста на DMAR-помилки, таймаути FLR і AER.
Якщо хост чистий — дивіться логи гостя і версії драйверів.

Чи необхідний один USB-контролер на VM?

Для високої стабільності — так. Долювати контролер між кількома гостями не типово, бо одна фізична PCIe-функція не може безпечно
належати кільком ОС одночасно. Якщо потрібно кілька ізольованих USB-доменів — додайте більше контролерів.

Наступні кроки, які ви можете зробити сьогодні

Відкрийте dmesg на хості і підтвердіть «Interrupt remapping enabled.» Якщо його немає — спочатку виправте налаштування прошивки.
Виберіть правильний USB-контролер: дискретна карта, ізольована IOMMU-група, не життєва лінія хоста.
Прив’яжіть його до vfio-pci рано через конфіг модулів + initramfs, а не через ad-hoc перев’язування після завантаження.
Запустіть тест перезавантажень і навантаження: повторні перезавантаження гостя плюс тривале USB-навант��ження, спостерігаючи DMAR-помилки, таймаути FLR і AER-повідомлення.
Якщо все ще нестабільно, перестаньте крутити налаштування і поміняйте контролер або платформу. Деякі комбінації — просто невдалі шлюби.

Мета не зробити передачу USB «працюючою». Мета — зробити її передбачуваною. Передбачувані системи — це ті, якими можна оперувати без особистого роману з логами.