Найкращі материнські плати для чистих IOMMU груп: на що звернути увагу перед покупкою

Що насправді означає «чисті IOMMU групи» (і навіщо це вам)

IOMMU група — це найменший набір PCIe‑пристроїв, який ваша платформа може надійно ізолювати для DMA (direct memory access). Якщо два пристрої ділять групу, ядро припускає, що їх не можна безпечно розділити, бо апаратне забезпечення не надає необхідних меж доступу між ними.

«Чисті» групи на практиці означають:

• Цільовий пристрій один у своїй групі (або лише в парі з нешкідливою функцією, яку також можна передати, наприклад HDMI‑аудіо GPU).
• Без несподіваних сусідів, як контролер SATA, USB‑контролер або кореневий порт чіпсету, що тягне за собою половину плати в ту саму групу.
• Стабільні групи між перезавантаженнями, оновленнями BIOS і ядра — бо ваш продакшн‑хост не має дружити з недовірою.

Чому це важливо: VFIO passthrough залежить від правильної межі IOMMU. Якщо ви передаєте пристрій, який ділить IOMMU групу з пристроєм, що все ще використовується хостом, у вас є три погані опції:

1. Не передавати його («сумно, але безпечно»).
2. Передати всю групу (іноді прийнятно, часто неможливо).
3. Використати ACS override, щоб підтасувати розділення (іноді працює, знижує гарантії ізоляції і може створити дивні режими відмови).

Чисті групи — це особливість материнської плати, а не трюк Linux. Linux лише повідомляє те, що платформа показує.

Жарт №1: Якщо ваш GPU ділить IOMMU групу з USB‑контролером, вітаю — ваша миша тепер «графічний аксесуар».

Як формуються IOMMU групи: CPU root‑порти, чіпсет і ACS

Ментальна модель: дерево з пунктами контролю

PCIe — це ієрархія. Ваш CPU забезпечує root‑комплекси й root‑порти. Чіпсет (PCH у Intel, «чіпсет» на платформах AMD) підключається до CPU і додає більше downstream‑портів, SATA, USB та інші інтегровані контролери.

IOMMU групи залежать від того, де пристрої розташовані в цьому дереві, і чи реалізують комутатори/мости між ними ACS (Access Control Services). ACS — це механізм, яким інфраструктура забороняє пристроям виконувати peer‑to‑peer DMA в обхід межі IOMMU. Якщо ACS відсутній (або не увімкнений), ядро групує пристрої разом, бо не може довести ізоляцію.

Лінії CPU: найчистіша нерухомість

Пристрої, підключені безпосередньо до root‑портів CPU, зазвичай мають кращі групування, ніж пристрої за чіпсетом. Тому «GPU у верхньому x16 слоті, підключеному до CPU» — це не лише рекомендація по продуктивності, а й рекомендація по ізоляції.

На сучасних платформах CPU зазвичай пропонує:

• Один x16 (часто бікфуркатований як x8/x8 або x8/x4/x4) для GPU/HBA/NVMe‑каркасів
• Один або кілька x4 лінків для NVMe
• Лінк до чіпсету

Кожен з них — окремий шлях, де природно можуть утворюватися межі IOMMU груп.

Лінії чіпсету: більше портів — більше шарингу

Чіпсет — це пристрій‑«вентилятор», підключений до CPU одним аплінком (DMI у Intel, аналогічна концепція у AMD). Багато вбудованих пристроїв підвішені на чіпсеті: додаткові NVMe слоти, контролери SATA, USB, Wi‑Fi, 2.5GbE, іноді навіть PCIe‑слот.

Це означає дві речі:

• Пристрої, підключені через чіпсет, можуть частіше опинятися в спільних IOMMU групах, особливо якщо мости не мають ACS або прошивка конфігурує консервативно.
• Навіть якщо групи «достатньо чисті», інтенсивний I/O на пристроях чіпсету може конкурувати по каналу аплінку і виглядати як проблема IOMMU, коли насправді це насичення каналу.

ACS: функція, яку ви хочете, і чекбокс, якого може не бути

ACS існує в кількох формах (source validation, P2P request redirect, completion redirect, upstream forwarding). У практичних термінах VFIO ви хочете, щоб платформа виставляла достатньо ACS, щоб downstream‑пристрої можна було відокремити в свої окремі групи.

Деякі плати показують в BIOS такі перемикачі:

• Above 4G decoding (часто потрібно для великих BAR GPU та для стабільного passthrough)
• Resizable BAR (іноді покращує продуктивність; також може ускладнювати скиди і відображення в деяких стеках)
• IOMMU / SVM (AMD) або VT-d (Intel)
• ACS увімкнути/вимкнути або опція «PCIe ARI/ACS» (рідше на споживчих платах)
• PCIe bifurcation для кожного слота

Вендори плат не стандартизують назви. Половина роботи — знати синоніми для пошуку в BIOS.

Не плутайте «групування» з «підключенням ліній»

Підключення ліній визначає пропускну здатність і місце підключення (CPU vs чіпсет). Групування IOMMU стосується меж ізоляції. Вони корелюють, але не ідеально. Я бачив плати з відмінною проводкою ліній, але жахливим групуванням через те, що прошивка не відкрила ACS належним чином. Навпаки, бачив споживчі плати з дивно хорошими групами, бо root‑порти CPU були чистими, а мости чіпсету реалізували ACS коректно.

Ознаки при покупці: на що звертати увагу перед покупкою

1) Віддайте пріоритет слотам, що підключені до CPU, для пристроїв, які плануєте передавати

Перед покупкою визначте, що саме ви збираєтеся передавати, і зіставте це з лініями CPU:

• Пасстру основного GPU: верхній x16 слот, приєднаний до CPU.
• Другий GPU / швидкісний NIC: другий слот, підключений до CPU (x8), якщо є.
• NVMe passthrough: M.2 підключений до CPU (часто в керівництві позначено як «from CPU», якщо пощастить).
• HBA passthrough: слот, підключений до CPU, якщо вам важлива чистота груп і передбачувані скиди.

Якщо плата має тільки один слот, підключений до CPU, а все інше йде через чіпсет, ваше IOMMU‑життя швидко ускладниться.

2) Вимагайте явної підтримки в BIOS для IOMMU/VT‑d і Above 4G decoding

Якщо в мануалі, скріншотах BIOS або на форумах підтримки не видно перемикачів для:

• IOMMU / SVM (AMD) або VT‑d (Intel)
• Above 4G decoding

…йдіть геть. «Ймовірно, воно є» — це те, як ви опиняєтеся з ACS override і переконуєте себе, що все нормально, бо сервер «не на публіці». Це не модель безпеки; це оптимізм.

3) Шукайте ознаки робочої станції: bifurcation, дружність до SR‑IOV, стабільна прошивка

Споживчі плати можуть працювати. Багато з них — так. Але якщо це продакшн‑гіпервайзер (або homelab, який ви тримаєте як продакшн), плати, орієнтовані на робочі станції/сервера, зменшують дивності:

• Налаштування PCIe bifurcation на слот (x16 → x8/x8, x8/x4/x4), щоб використовувати NVMe‑карти‑носії без PCIe‑світча.
• Стабільна тактика AGESA/ME‑прошивки, де оновлення не змінюють випадково PCIe‑перерахунок.
• Краще звітування помилок (WHEA логи, поведінка AER) і менше «ігрових оптимізацій».

4) Розумійте, що інтегровані контролери можуть «запоїти» групи

Материнські плати люблять додавати «корисні» контролери за спільними містками: додаткові SATA‑чіпи, додаткові USB‑контролери, Wi‑Fi, RGB‑контролери, іноді навіть Thunderbolt‑доповнення. Кожен додатковий пристрій може приклеїтися до групи, яку ви хотіли б тримати чистою.

Практичні поради:

• Якщо хочете чисті групи, не купуйте плату з купою «фішок». Купуйте плату з більшою кількістю нудних компонентів.
• Віддавайте перевагу Intel NIC (або серверним Broadcom) над випадковими «геймерськими» NIC, якщо це серйозно. Це не строго про IOMMU, але зменшує хаос драйверів.
• Уникайте плат, які пропускають другий «x16» слот через чіпсет, попри те, що він механічно x16. Механічний — не означає електричний.

5) Перевіряйте звіти спільноти, але ставтеся до них як до прогнозу погоди

Звіти користувачів про IOMMU групи корисні, але не догма. Версія BIOS, покоління CPU і навіть які M.2 слоти заповнені можуть змінити топологію. Використовуйте звіти для створення шорт‑ліста, а не для підписання замовлення на покупку.

6) Вирішіть зараз: ви приймаєте ACS override чи ні?

ACS override у Linux може розділити групи, прикидаючись, що ACS існує там, де його немає. Це інструмент; це також компроміс. В середовищах, де ізоляція має значення (multi‑tenant, неперевірені навантаження, відповідність), вважайте його неприйнятним.

В одиночному homelab‑сценарії, де ви довіряєте своїм VM і прагнете функціональності, це може бути «достатньо», але ставтеся до цього як до тимчасової лісі, а не до фундаменту.

7) Плануйте скиди і обробку квірків (особливо для GPU)

Чисті групи — не єдина «плата‑залежна» частина passthrough. Поведінка скиду GPU, підтримка FLR (Function Level Reset) і енергетичні налаштування платформи можуть визначати, чи перезавантажиться VM чисто або «застрягне» пристрій до перезавантаження хоста.

Якщо купуєте спеціально для GPU passthrough, схиляйтеся до:

• Платформ, відомих хорошою поведінкою з вашим вендором GPU (AMD/NVIDIA/Intel ARC) під VFIO
• Плат з менше сторонніх PCIe‑світчів і меншою кількістю «хитрих» шарингів ліній

Поради по платформі: AMD vs Intel, споживчі vs робочі станції vs сервери

AMD споживчі (AM4/AM5): часто хороші групи, іноді рулетка прошивки

Мейнстрим‑платформи AMD можуть виявитися надзвичайно дружніми до VFIO. Багато AM4 плат здобули репутацію за пристойне групування IOMMU, особливо коли GPU і основний NVMe підключені до CPU. AM5 продовжує цю тенденцію, але вводить новішу прошивку і складнішу поведінку PCIe 5.0.

Що віддавати перевагу:

• Плати, які ясно документують, які M.2 слоти підключені до CPU, а які — до чіпсету
• BIOS, що показує IOMMU, SVM, Above 4G і налаштування bifurcation по слотах
• Менше вбудованих контролерів, якщо вам важлива чистота груп

Чого уникати:

• Плат з «додатковими» PCIe‑містками заради косметичної кількості слотів
• Прошивки, що ховають розширені PCIe‑налаштування за «EZ mode forever»

Intel споживчі (LGA1200/1700/1851‑ish): VT‑d зрілий; фан‑аут чіпсету може створювати проблеми

Intel VT‑d зрілий. Більшість проблем не в VT‑d як такому; проблема в тому, як плата прокладає пристрої через PCH і чи відкриває прошивка достатній ACS. Intel‑споживчі плати часто мають багато пристроїв на чіпсеті: Wi‑Fi, кілька M.2, кілька USB‑контролерів, іноді підтримку Thunderbolt.

Що віддавати перевагу:

• Плати з сильними BIOS‑опціями для VT‑d, Above 4G decoding і bifurcation
• Чіткі діаграми підключення слотів у мануалі

Чого уникати:

• Thunderbolt‑доповнення, якщо вони вам не потрібні (вони додають додаткові мости і питання безпеки)
• «Геймерські» плати з купою контролерів за спільними містками

Платформи для робочих станцій (Threadripper/WRX80, Xeon W): нудно, дорого і зазвичай правильно

Якщо вам потрібно кілька пристроїв для passthrough без компромісів — кілька GPU, кілька NIC, HBA та NVMe — платформи для робочих станцій — це дорослий вибір. Ви купуєте більше ліній CPU, більше root‑портів і платформу, що очікує віртуалізації.

Що ви отримуєте:

• Більше PCIe‑слотів підключених до CPU (менше залежності від чіпсетного фан‑ауту)
• Кращі шанси на чисті групи без ACS override
• Часто краща підтримка SR‑IOV і корпоративних мережевих карт

Чим це обходиться:

• Гроші, звісно
• Енергоспоживання і складність охолодження
• Іноді повільніша динаміка споживчих фішок (бо стабільність — це фіча)

Серверні платформи: найкраща ізоляція, але не думайте, що «сервер» = «дружній для passthrough»

Серверні плати часто надають відмінну ізоляцію, але аудиторія зазвичай орієнтована на PCIe‑пристрої, якими керує хост, а не на передачу у довільні десктопні VM. Ви можете зіткнутися з:

• Дефолтами BIOS, які віддають пріоритет віддаленому керуванню та стабільності над споживчим комфортом
• Вбудованими пристроями, які важко відключити (BMC, додаткові мости)
• Особливостями з конс’юмерськими GPU (стани живлення, ініціалізація, відсутність підтримки option ROM)

Якщо ви робите GPU passthrough на серверній платі, рано перевіряйте конкретну модель GPU та поведінку при скиді.

Суб’єктивна думка: Якщо ваш план включає більше ніж один GPU для passthrough і один NVMe для passthrough, перестаньте намагатися «виграти» зі споживчим чіпсетом. Порахуйте варіант з платформою для робочої станції. Ви купите її рано чи пізно — або зараз, або після того, як заплатите «податок на дебаг».

Цікаві факти та коротка історія (щоб дивність стала зрозумілою)

• Факт 1: IOMMU в AMD брендується як AMD‑Vi; еквівалент Intel — VT‑d. Обидва вирішують ту саму основну проблему: контроль DMA пристроїв.
• Факт 2: PCIe ACS не завжди був поширений у споживчому сегменті; ранні прихильники VFIO часто спиралися на хаки чіпсету та патчі ядра.
• Факт 3: Фреймворк Linux VFIO з’явився як чистіший шлях у порівнянні з застарілими методами, підкреслюючи призначення пристрою з IOMMU як межі безпеки.
• Факт 4: «Above 4G decoding» — стара концепція: вона потрібна, бо PCIe‑пристрої потребують адресного простору для MMIO BAR, а сучасні GPU можуть вимагати багато.
• Факт 5: Resizable BAR (фіча PCIe) стала масовою з сучасними GPU; вона змінює обсяг VRAM, відображений у адресному просторі CPU, що може впливати на passthrough‑налаштування.
• Факт 6: PCIe bifurcation не гарантується формою слота; це функція платформи/прошивки. Два x8 пристрої в одному x16 слоті — рішення BIOS.
• Факт 7: «Чіпсетний аплінк» (Intel DMI або еквівалент) — це спільна труба; швидкий NVMe за чіпсетом може наситити її і виглядати як латентні примари.
• Факт 8: FLR (Function Level Reset) — це можливість PCIe, яка робить passthrough‑пристрої більш дружніми до життєвого циклу VM. Багато пристроїв все ще погано її реалізують.
• Факт 9: Склад IOMMU груп може змінюватися при заповненні певних M.2 слотів, бо плата може перемаршрутовувати лінії або вмикати інші мости.

Одна перефразована ідея, яку люди з операцій повторюють, бо вона постійно вірна: перефразована ідея — W. Edwards Deming (перефразовано): «Погана система переможе хорошу людину щоразу.»

Командний preflight: 12+ практичних завдань і як вирішувати за результатами

Ці завдання припускають Linux‑хост (Debian/Ubuntu/Proxmox типово). Вони створені, щоб швидко відповісти на три питання:

1. Чи IOMMU справді увімкнено?
2. Які IOMMU групи існують?
3. Чи можна безпечно прив’язати цільовий пристрій до vfio‑pci без шкоди для хоста?

Завдання 1: Підтвердити CPU‑флаги віртуалізації

cr0x@server:~$ lscpu | egrep 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-13900K
Virtualization:                  VT-x

Що це означає: VT‑x/AMD‑V — це CPU‑віртуалізація. Потрібна, але недостатня для passthrough пристроїв.

Рішення: Якщо віртуалізація відсутня, спочатку увімкніть CPU‑віртуалізацію в BIOS. Не думайте про IOMMU доти.

Завдання 2: Підтвердити підтримку IOMMU і чи воно увімкнено при завантаженні

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.210000] DMAR: Intel(R) Virtualization Technology for Directed I/O

Що це означає: «DMAR: IOMMU enabled» (Intel) або «AMD‑Vi: IOMMU enabled» (AMD) — зелений сигнал.

Рішення: Якщо бачите «IOMMU disabled» або нічого релевантного, увімкніть VT‑d/IOMMU у BIOS і додайте параметри ядра.

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

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

Що це означає: Для Intel — intel_iommu=on. Для AMD зазвичай — amd_iommu=on. iommu=pt часто використовується, щоб зменшити накладні витрати для хост‑пристроїв (pass‑through режим для не‑призначених пристроїв).

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

Завдання 4: Перерахувати IOMMU групи (найкорисніша команда)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; for d in "$g"/devices/*; do lspci -nn -s "${d##*/}"; done; echo; done | less
IOMMU Group 16
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

IOMMU Group 17
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

IOMMU Group 18
00:14.0 USB controller [0c03]: Intel Corporation USB 3.2 Controller [8086:7ae0]
00:14.2 RAM memory [0500]: Intel Corporation Shared SRAM [8086:7aa7]

Що це означає: Ваш GPU — чистий (тільки власні функції). NVMe — один. USB‑контролер згрупований з функцією чіпсету (нормально).

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

Завдання 5: Зіставити фізичний слот зі PCIe‑адресою

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvme|ethernet'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]

Що це означає: PCI‑адреси (domain:bus:slot.function) — це те, як ви ідентифікуєте пристрої для біндингу і passthrough.

Рішення: Запишіть адреси пристроїв, які збираєтеся передавати.

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3901
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Хост зараз використовує GPU через nvidia.

Рішення: Якщо ви хочете passthrough, хост не повинен використовувати пристрій. Плануйте прив’язати його до vfio-pci рано в процесі завантаження.

Завдання 7: Визначити vendor/device ID для прив’язки vfio‑pci

cr0x@server:~$ lspci -nn -s 01:00.0 -s 01:00.1
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

Що це означає: Ви будете прив’язувати 10de:2484 і 10de:228b до vfio‑pci.

Рішення: Завжди прив’язуйте всі функції в одній групі (наприклад GPU + аудіо), якщо у вас немає конкретної причини інакше.

Завдання 8: Перевірити, що модулі VFIO доступні та завантажені

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          73728  1 vfio_pci
vfio_iommu_type1       40960  0
vfio                   24576  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             442368  0
kvm                  1306624  1 kvm_intel

Що це означає: Ядро має завантажений VFIO.

Рішення: Якщо VFIO відсутній, встановіть відповідний пакет ядра/модулів або увімкніть їх у вашому дистрибутиві.

Завдання 9: Сухий запуск прив’язки за допомогою driver_override (тест у runtime)

cr0x@server:~$ echo vfio-pci | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver_override
vfio-pci
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind
0000:01:00.0
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/bind
0000:01:00.0

Що це означає: Ви можете прив’язати пристрій до vfio‑pci у runtime. Якщо не вдається — пристрій може бути зайнятий або заблокований груповими обмеженнями.

Рішення: Якщо runtime‑прив’язка не вдається, не робіть її постійною ще. Усуньте причину (консоль використовує GPU, framebuffer, аудіо тощо).

Завдання 10: Підтвердити, що пристрій тепер належить vfio‑pci

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Драйвер хоста більше не приєднаний; vfio‑pci контролює пристрій.

Рішення: Тепер ви можете налаштувати гіпервізор для призначення пристрою VM.

Завдання 11: Перевірити підказки про ACS/PCIe AER у логах ядра, коли групи виглядають неправильно

cr0x@server:~$ dmesg | egrep -i 'ACS|AER|PCIe|Downstream|Upstream' | head -n 40
[    0.812345] pci 0000:00:1c.0: PCIe Downstream Port
[    0.812678] pci 0000:00:1c.0: ACS not supported
[    0.900123] pcieport 0000:00:1c.0: AER enabled with IRQ 122

Що це означає: Downstream‑порт не підтримує ACS; це може змушувати групуватися.

Рішення: Якщо пристрій, про який вам важливо, висить за мостом без ACS, краще перенести його в слот, прив’язаний до CPU, або змінити плату/платформу. ACS override — крайній засіб.

Завдання 12: Визначити, чи пристрій підтримує скидання (FLR) і як він поводиться

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'Capabilities: \[.*\] Express|FLR|Reset' -n
45:Capabilities: [68] Express (v2) Endpoint, MSI 00
92:	DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
130:	Capabilities: [100] Advanced Error Reporting
161:	Capabilities: [250] Latency Tolerance Reporting

Що це означає: Не всі пристрої явно рекламують FLR простим grep‑ом, і квірки скиду GPU поширені.

Рішення: Якщо ви бачите повторювані «зависання пристрою» при перезавантаженні VM, можливо, потрібні модулі для скиду від вендора, інша модель GPU або інший слот/прошивка платформи.

Завдання 13: Перевірити huge BAR / тиск адресного простору (поширено з сучасними GPU)

cr0x@server:~$ dmesg | egrep -i 'BAR|resizable|MMIO|above 4g' | head -n 50
[    1.234567] pci 0000:01:00.0: BAR 0: assigned [mem 0x6000000000-0x600fffffff 64bit pref]
[    1.234890] pci 0000:01:00.0: BAR 2: assigned [mem 0x6010000000-0x6011ffffff 64bit pref]
[    1.235012] pci 0000:01:00.0: enabling device (0000 -> 0003)

Що це означає: Великі BAR‑мапінги потребують належної підтримки прошивки. Якщо призначення адрес не вдається, passthrough може зламатися або пристрої можуть зникнути.

Рішення: Якщо бачите помилки BAR‑призначення або пристрої не з’являються, увімкніть Above 4G decoding; тимчасово відключіть Resizable BAR під час налагодження.

Завдання 14: Перевірити, які пристрої за чіпсетом, а які — за CPU (вигляд топології)

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0  Intel Corporation Device 1234
           +-01.0-[01]----00.0  NVIDIA Corporation GA104 [GeForce RTX 3070]
           +-02.0-[02]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller
           +-14.0  Intel Corporation USB 3.2 Controller
           \-1c.0-[03]----00.0  Intel Corporation I210 Gigabit Network Connection

Що це означає: Дерево допомагає побачити, чи пристрій висить за певним root‑портом/мостом. Пристрої за одним downstream‑портом частіше ділять групу, якщо ACS слабкий.

Рішення: Віддавайте перевагу пристроям для passthrough, що прямо підключені під окремі root‑порти.

Завдання 15: Перевірити, що ваш initramfs прив’яже vfio рано (щоб хост не захопив пристрої)

cr0x@server:~$ grep -R "vfio" /etc/modprobe.d /etc/modules /etc/initramfs-tools 2>/dev/null | head
/etc/modules:vfio
/etc/modules:vfio_iommu_type1
/etc/modules:vfio_pci
/etc/modprobe.d/vfio.conf:options vfio-pci ids=10de:2484,10de:228b disable_vga=1

Що це означає: Конфігурація існує для ранньої прив’язки ID до vfio‑pci.

Рішення: Якщо відсутня, додайте і перебудуйте initramfs, щоб драйвери графіки/аудіо хосту не прив’язувалися першими.

Завдання 16: Перебудувати initramfs і підтвердити, що це пройшло успішно

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-amd64

Що це означає: Ваш ранній середовищний образ тепер містить конфіг для прив’язки VFIO.

Рішення: Перезавантажте і перевірте знову Завдання 6/10, щоб переконатися, що vfio‑pci володіє пристроєм під час завантаження.

Швидкий план діагностики: що перевірити першим/другим/третім, щоб швидко знайти вузьке місце

Перше: IOMMU увімкнено і працює?

• Перевірте /proc/cmdline на intel_iommu=on або amd_iommu=on (Завдання 3).
• Перевірте dmesg на DMAR/AMD‑Vi enabled (Завдання 2).
• Якщо відсутнє: BIOS‑перемикачі (VT‑d/IOMMU, Above 4G) і параметри ядра. Перезавантажте.

Друге: чи IOMMU групи роблять passthrough можливим?

• Здампіть IOMMU групи (Завдання 4).
• Знайдіть групу цільового пристрою і перелічіть все, що в ній.
• Якщо група містить критичні для хоста пристрої (USB‑контролер потрібний для клавіатури на headless, boot NVMe, основний NIC): не продовжуйте.

Третє: чи стабільна поведінка скиду/прив’язки пристрою?

• Перевірте володіння драйвером (lspci -k) (Завдання 6/10).
• Спробуйте runtime bind/unbind (Завдання 9).
• Спостерігайте dmesg під час старту/зупинки VM на предмет помилок (Завдання 11/13).
• Якщо перезавантаження VM «застрягло» пристрій: у вас проблема скиду, а не групування.

Четверте: це справді проблема IOMMU чи проблема пропускної здатності/латентності?

• Використайте lspci -t, щоб побачити, чи ваші «швидкі» пристрої всі за чіпсетним аплінком (Завдання 14).
• Якщо ви насичуєте аплінк чіпсету, перемістіть високонавантажені пристрої на лінії CPU або прийміть обмеження.

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

1) Симптом: GPU ділить групу з USB/SATA/NIC

Коренева причина: GPU знаходиться за мостом без ACS або за чіпсетом, який не може ізолювати пристрої; іноді слот підключений через чіпсет.

Виправлення: Перемістіть GPU в слот, підключений до CPU. Вимкніть непотрібні вбудовані контролери в BIOS, якщо можливо. Якщо й надалі група спільна — змініть материнську плату/платформу. Використовуйте ACS override тільки якщо погоджуєтеся на слабшу ізоляцію.

2) Симптом: IOMMU групи виглядають нормально, але запуск VM падає з «device is in use»

Коренева причина: Драйвер хоста захопив пристрій дуже рано (framebuffer, аудіо, драйвер вендора GPU).

Виправлення: Прив’яжіть ID пристрою до vfio-pci у конфігах modprobe і перебудуйте initramfs (Завдання 15/16). Переконайтеся, що хост не використовує GPU для консолі.

3) Симптом: VM запускається один раз; другий запуск зависає або GPU зникає до перезавантаження хоста

Коренева причина: Проблеми зі скидом/FLR; поширені для деяких GPU і певної поведінки енергоменеджменту плати.

Виправлення: Спробуйте інший слот (інший root‑порт). Вимкніть агресивний ASPM у BIOS. Розгляньте модулі для reset від вендора, де застосовно. У найгіршому випадку — оберіть іншу модель GPU, відому коректним скиданням.

4) Симптом: Увімкнення Above 4G decoding ламає завантаження або ховає пристрої

Коренева причина: Баг прошивки або конфліктні налаштування (CSM, legacy option ROM, дивна PCIe‑мапінг).

Виправлення: Вимкніть CSM/legacy boot, використайте UEFI. Оновіть BIOS. Якщо проблема лишається — плата показує, ким вона є — повірте їй.

5) Симптом: NVMe passthrough працює, але під навантаженням продуктивність нестабільна

Коренева причина: NVMe підключений через чіпсет і конкурує на аплінку; це не проблема IOMMU групування.

Виправлення: Перемістіть NVMe на CPU‑підключений M.2 або використайте слот CPU з каркою‑носієм (з bifurcation). Або прийміть обмеження аплінку і скоригуйте очікування.

6) Симптом: SR‑IOV «працює», але VF опиняються в дивних групах або не призначаються

Коренева причина: Обмеження прошивки/драйвера NIC, межі відображення IOMMU або поведінка ACS навколо PF/VF.

Виправлення: Оновіть прошивку NIC. Перевірте, що IOMMU увімкнено і поведінку iommu=pt. Віддавайте перевагу серверним/робочим платам і NIC, відомим стабільністю SR‑IOV.

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

Чеклісти / покроковий план

Крок 1: Визначте, що саме будете передавати (будь‑ласка, конкретно)

• Які GPU? Включно з аудіофункцією.
• Які NVMe? Boot vs passthrough.
• Які NIC? Потрібен SR‑IOV?
• Будь‑який passthrough USB‑контролер (для VR, донглів, ліцензійних ключів)?

Крок 2: Оберіть платформу, виходячи з потреб по лініях, а не з виду

• Один GPU + один NVMe passthrough: багато споживчих плат з цим впораються.
• Два GPU + кілька NVMe/NIC/HBA для passthrough: орієнтуйтеся на робочі станції (більше ліній CPU, більше root‑портів).
• Відповідність або неперевірені VM: уникайте ACS override як стратегії.

Крок 3: Чекліст при виборі материнської плати (до покупки)

• Мануал показує проводку слотів (CPU vs чіпсет) і правила шарінгу ліній.
• BIOS підтримує: IOMMU/VT‑d, Above 4G decoding, per‑slot bifurcation.
• Менше сторонніх контролерів, якщо вони вам не потрібні.
• Звіти про чисті IOMMU групи на схожих CPU/BIOS версіях (як підказка, не як доказ).
• Фізичне розташування дозволяє охолодження при заповненні декількох PCIe‑слотів.

Крок 4: Зберіть і валідуйте на столі (до міграції важливих сервісів)

1. Встановіть хост‑ОС.
2. Увімкніть налаштування BIOS (IOMMU/VT‑d, 4G decoding, UEFI boot).
3. Завантажтеся і виконайте Завдання 2–4, щоб перевірити IOMMU групи.
4. Прив’яжіть спочатку некритичний пристрій (запасний NIC або USB‑контролер) до VFIO, щоб перевірити потік VFIO.
5. Тільки потім прив’язуйте GPU/NVMe, що вас цікавлять.

Крок 5: Закріпіть налаштування (щоб відтворювалося)

• Зафіксуйте версію BIOS і налаштування (скріншоти або текст).
• Прив’яжіть версію ядра, якщо стабільність важливіша за новизну.
• Тримайте відомий‑good пункт завантаження у завантажувачі.
• Документуйте PCI‑адреси і IOMMU групи як частину нотаток щодо збірки хоста.

Три міні‑історії з корпоративного життя (що фактично йде не так)

Історія 1: Інцидент через неправільне припущення

Вони збирали невеликий кластер для внутрішнього графічного пайплайну: кілька потужних хостів, по кілька GPU на кожен, і дедлайн, що вже був емоційно нестабільним. Хтось вибрав материнську плату за відгуками «чудово для ігор, купа PCIe слотів». Насправді в ній було багато слотів. Електрично — амбіції були скромні.

Перший хост підняли і команда зробила те, що робить кожен: увімкнули VT‑d/IOMMU, Above 4G decoding, поставили гіпервізор і спробували передати GPU. Одна GPU виглядала нормально. Друга GPU поділила IOMMU групу з USB‑контролером і SATA‑контролером. Передача цієї групи забрала б завантажувальний диск хоста і його віддалену клавіатуру.

Вони припустили, що ядро‑твік виправить це. Увімкнули ACS override. Воно «працювало» в сенсі, що вони могли призначити GPU VM. Потім VM впала під навантаженням і хост втратив дисковий пристрій. Не було корупції даних, на щастя — просто зворотний режим лише для читання і форсований ребут у продакшні. Коренева причина не була зловмисною VM; причиною була платформа, що не мала реальної ізоляції, і ядро, якому попросили прикинутися.

Постмортем був простий і болісний: команда припустила, що кількість слотів означає незалежні root‑порти і межі ACS. Це не так. Механічні x16 слоти дешеві; чисті IOMMU межі — ні.

Вони замінили плати на робочо‑станційного класу з меншою кількістю «фішок» і більшою кількістю ліній. Все стало нудним. Ніхто не жалкує про втрату RGB.

Історія 2: Оптимізація, що зіграла злий жарт

Інша команда вела приватний хмарний проект зі змішаними вузлами обчислень і зберігання. Вони хотіли максимізувати щільність: більше NVMe, більше NIC і ще слот для випадкового GPU тесту. «Оптимізація» була у використанні PCIe‑світча, щоб розгорнути лінії і втиснути більше пристроїв у меншу кількість root‑портів CPU.

На папері — елегантно: один x16 слот ставав чотирма x4 NVMe плюс NIC деінде. На практиці PCIe‑світч привніс поведінку групування, яка їх здивувала. Декілька кінцевих точок опинилися в одній IOMMU групі, бо upstream‑порт не виставляв ACS у той спосіб, як Linux очікує. Плани passthrough швидко ускладнилися.

Вони намагалися пройти через: передавали цілі групи, переміщали пристрої, перемикали BIOS‑налаштування і сперечалися, чи важливий перфоманс від iommu=pt для їхнього навантаження. Зрештою, їм вдалося запустити щось — але кожне оновлення ядра ставало ризиком. Порядок нумерації змінився одного разу, і конфіг VM, що спирався на адресу пристрою, опинився з неправильним NVMe. Це виявили на стейджингу, але це було гучним попередженням.

Виправлення було нудним: вони перестали оптимізувати щільність слотів і почали оптимізувати ізоляцію. Використали менше свічів, більше прямих ліній CPU і погодилися на трохи більший розмір вузла. Бізнес‑вихід — краща доступність і менше ночних розслідувань «чому змінилася група 27?».

Історія 3: Нудна, але правильна практика, що врятувала день

Організація, близька до фінансів, мала невеликий набір гіпервізорів, що хостили внутрішні робочі столи з GPU‑прискоренням. Нічого публічного в інтернеті, але все одно чутливо. Їх SRE‑лідер мав правило: кожна апаратна платформа проходить «hardware acceptance test» перед допуском у флот.

Тест не був гламурним. Це був скрипт, що дампив IOMMU групи, знімав lspci -t, фіксував налаштування BIOS і перевіряв, чи цільові пристрої можуть прив’язатися до vfio‑pci без ACS override. Також вони вимагали повний життєвий цикл VM: завантаження, завантаження драйвера, короткий стрес, перезавантаження VM, повтор. Якщо GPU зависав при перезавантаженні, ця модель GPU або слот відкидалися.

Одного кварталу постачальник пообновив BIOS і acceptance test провалився на новій партії машин: другий NVMe тепер ділив групу з USB‑контролером чіпсету. Для звичайного десктоп‑використання нічого «не ламалося». Для passthrough — це був неприйнятний стан.

Оскільки у них був тест і вони запускали його перед розгортанням, вони виявили проблему рано, затримали оновлення BIOS і підняли питання до вендора з чистими доказами: до/після карти груп і топології. Флот залишився стабільним. Зміна виправлена в наступному BIOS. Найцікавіше в інциденті було те, що нікому не довелося нічого робити пізно вночі.

Ось секрет: нудні перевірки запобігають хвилюючим аваріям.

FAQ

1) Яка «хороша» компоновка IOMMU груп для GPU passthrough?

Ідеал: GPU одинокий разом зі своєю аудіофункцією у тій же групі. Прийнятно: GPU ділиться з upstream‑мостом, який ви теж можете передати (рідко і залежить від випадку). Погано: GPU ділиться з USB/SATA/NIC, які потрібні хосту.

2) Чи дорожча материнська плата гарантує чисті групи?

Ні. Ціна купує фічі і іноді валідацію, але не гарантує розумну PCIe‑топологію. Плати для робочих станцій зазвичай краще, бо мають більше ліній CPU і більше root‑портів, а не через кращі радіатори.

3) Чи небезпечний ACS override?

Воно знижує гарантії ізоляції, змушуючи ядро вважати пристрої відокремленими, навіть якщо фабрика не може це забезпечити. У довірених одноосібних середовищах це може бути прийнятним. У multi‑tenant або чутливих до безпеки середовищах — неприйнятно.

4) Чому мої IOMMU групи змінюються при заповненні M.2 слота?

Тому що деякі плати шарять лінії між слотами або вмикають інші мости залежно від того, які слоти заповнені. Додавання NVMe може змінити, як будується PCIe‑дерево, що змінює групування.

5) Чи завжди пристрої, підключені через чіпсет, погані для passthrough?

Не завжди. Деякі чіпсети/плати показують адекватну ACS‑поведінку і дають робочі групи. Більший ризик — спільна пропускна здатність аплінку і забруднення груп іншими пристроями чіпсету.

6) Чи потрібен Above 4G decoding для passthrough?

Часто так, особливо з сучасними GPU (великі BAR) або багатьма PCIe‑пристроями. Без нього ви можете бачити помилки при перерахунку пристроїв або BAR‑помилки.

7) Чи можу я передати лише GPU, а не його аудіофункцію?

Можете спробувати, але зазвичай чистіше передавати всі функції в групі. Розділення функцій може створити конфлікти драйверів або залишити хост‑драйвери, що «чіпають» пристрій.

8) Чому passthrough GPU працює до перезавантаження VM?

Це зазвичай проблема скиду (FLR не підтримується або працює неправильно; квірки енергоменеджменту). Спробуйте інший слот, змініть енергетичні налаштування BIOS або оберіть апарат, відомий коректними скидами.

9) Який найпростіший спосіб протестувати материнську плату на чисті групи перед покупкою?

Завантажте live‑Linux, увімкніть IOMMU/VT‑d і Above 4G у BIOS, потім виконайте дамп IOMMU груп (Завдання 4). Якщо ваш цільовий пристрій приклеєний до критичних для хоста пристроїв — повертайте плату, поки можете.

Практичні наступні кроки

1. Перелічіть пристрої для passthrough і вирішіть, які мають бути підключені до CPU.
2. Складіть шорт‑ліст плат, що документують проводку ліній і мають IOMMU + Above 4G + bifurcation у BIOS.
3. Тестуйте на столі точну конфігурацію (включно з заповненими M.2 слотами) і зафіксуйте IOMMU групи.
4. Відмовтеся від крихких рішень: якщо для роботи потрібен ACS override, або явно прийміть ризик, або змініть апаратне забезпечення.
5. Зробіть процес відтворюваним: зафіксуйте версію BIOS/налаштування і збережіть вивід команд, що доводять правильну ізоляцію хоста.

Якщо хочете просте правило, яке витримає тиск: купуйте за топологією, а не за маркетингом. Чисті IOMMU групи — не фіча, яку ввімкнуть пізніше. Це властивість, за яку платять наперед.