Intel VT-d проти AMD‑Vi: що насправді забезпечує кращу передачу PCIe‑пристроїв (passthrough)?

February 18, 2026 • February 18, 2026 • Читання: 6 хв • Views: 1

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

PCIe passthrough — це функція, яка на слайді виглядає детерміновано, але в продакшені поводиться як погода.
Один день ваша GPU‑VM поводиться як ідеальний громадянин; наступного дня вона чорний екран на перезавантаженні й ваше вікно технічного обслуговування перетворюється на групову терапію.

Питання «Чи краще Intel VT-d за AMD‑Vi?» зазвичай звучить одразу після покупки заліза і безпосередньо перед тим, як хтось пошкодує про якийсь BIOS‑параметр.
Реальна відповідь менше про логотипи і більше про конкретну поведінку платформи: групи IOMMU, перенаправлення переривань, якість прошивки і наскільки вам потрібна чиста ізоляція пристроїв.

Що «кращий passthrough» насправді означає

«Кращий passthrough» — це не одна метрика. У продакшені вас цікавлять чотири речі, приблизно в такому порядку:

Коректність ізоляції: пристрій знаходиться у власній групі IOMMU, DMA обмежено, та скидання працюють коректно.
Операційна стабільність: перезавантаження, live‑міграції (де застосовно), перезавантаження драйверів і оновлення ядра не перетворюються на інциденти.
Стабільність продуктивності: низька джиттерність під навантаженням і передбачувана затримка, особливо для NVMe, мережевих контролерів і GPU.
Керованість: хороша видимість у інструментах, адекватні логи і менше «спеціальних прапорів завантаження», які стають племінним знанням.

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

VT-d vs AMD‑Vi: стислий субʼєктивний висновок

І Intel VT-d, і AMD‑Vi (реалізація IOMMU від AMD) можуть забезпечити відмінний passthrough. Найбільші відмінності, які ви відчуєте, не теоретичні.
Вони в деталях реалізації платформи: прошивка материнської плати, топологія PCIe, групування IOMMU і наскільки надійне перенаправлення переривань.

Моя базова рекомендація

Якщо вам потрібен нудний, корпоративний passthrough (SR‑IOV NIC, HBA, NVMe, GPU у флоті): обирайте платформу з найкращою репутацією «плата + BIOS», а не тільки постачальника CPU.
На практиці це часто означає Intel‑платформи у сертифікованих серверах, або сучасні платформи AMD EPYC з витриманою прошивкою.
Якщо ви купуєте споживче залізо: системи AMD часто дають більше ядер за гроші, але також більше варіативності в групах IOMMU залежно від чіпсету і трасування плати.
Intel‑плати у споживчому сегменті можуть бути передбачуванішими, але іноді зустрічаються «спільні root‑port» ситуації.
Якщо ви покладаєтеся на чисті групи IOMMU і не терпите ACS override: пріоритезуйте платформи, що експонують більше PCIe root‑портів і чистішу ізоляцію downstream.
Це менше питання «Intel чи AMD» і більше — «ця конкретна материнська плата і покоління CPU».

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

Як IOMMU passthrough насправді працює (і де воно дає збій)

Passthrough — це контракт з трьох частин:

Пристрій виконує DMA і піднімає переривання.
IOMMU транслює DMA‑адреси пристрою через таблиці сторінок, обмежуючи, яку фізичну памʼять пристрій може торкатися.
Гіпервізор (KVM/QEMU через VFIO на Linux або type‑1 гіпервізор) привʼязує пристрій до гостя і програмує відображення IOMMU.

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

Погане групування: ваша GPU і контролер USB ділять групу IOMMU; ви не можете безпечно передати один без іншого.
Невдача скидання: гість вимикається, пристрій не скидається коректно, і наступне завантаження зависає на «Starting bootloader…» або показує чорний екран.
Проблеми з перериваннями: доставка MSI/MSI‑X дивна; продуктивність падає або затримки стрибають; деякі пристрої працюють лише з певними параметрами ядра.
Сторінкові збої: у dmesg зʼявляються IOMMU‑fault; драйвер у гості начебто справний, але відображення або поведінка ATS/PRI не відповідають очікуванням.

Також: passthrough — це проблема топології.
Два ідентичні CPU на різних материнських платах можуть поводитися як різні види, тому що ваша схема PCIe визначає, які пристрої сидять за якими root‑портами і мостами,
а це визначає групування і домени скидання.

Жарт №1: PCIe passthrough — це просто, поки ви не спробуєте.

Цікаві факти та історичний контекст (коротко, корисно)

Це не факти для вікторини. Вони пояснюють, чому виникають певні баги й особливості платформ.

VT-d зʼявився після VT‑x: віртуалізація CPU (VT‑x) сама по собі не давала безпечного DMA, тому VT‑d закрив цю прогалину для спрямованого I/O.
AMD‑Vi в логах Linux називають просто IOMMU: Linux часто повідомляє реалізацію AMD під загальною назвою IOMMU, і ви побачите «AMD‑Vi» в dmesg на багатьох системах.
Перенаправлення переривань — це фіча надійності: це не лише про продуктивність — без нього ви можете змушені перейти до менш безпечних або менш функціональних режимів обробки переривань.
ACS — це функція PCIe, а не IOMMU: Access Control Services допомагає посилити ізоляцію між downstream‑портами; відсутність ACS часто призводить до неприємного групування.
«ACS override» — це Linux‑хак: він може розділити групи IOMMU, удаючи, що ізоляція ACS існує. Іноді це нормально; іноді — самонадія.
SR‑IOV зробив IOMMU масовим: коли NIC почали представляти множинні віртуальні функції, коректність IOMMU перестала бути нішею і стала табличною вимогою в ЦОДах.
DMAR — ACPI‑таблиця Intel для IOMMU: якщо DMAR‑таблиці помилкові, VT‑d може бути «увімкнений», але фактично ненадійний.
AMD IOMMU використовує IVRS‑таблиці: аналогічно, неправильні IVRS‑записи можуть призвести до відсутніх пристроїв, поламаних відображень або заплутаної топології груп.
Біль проблем зі скиданням GPU має історичні корені: багато GPU спочатку не проектувалися для частих функціональних скидань у віртуалізованому середовищі, тож ви успадковуєте апаратні припущення від голого металу.

Різниці платформ, що змінюють результати

1) Якість груп IOMMU: мовчазний король

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

Intel vs AMD тут не моральне змагання. Це про комбінацію:
інтегрованих в CPU PCIe root‑комплексів, ліній чіпсету, onboard PCIe‑комутаторів/ретаймерів і трасування плати.
Серверні плати зазвичай чистіші за споживчі. Робочі станції можуть бути або раєм, або карнавалом.

2) Перенаправлення переривань: різниця між «нормально» і «чому така джиттерність?»

При passthrough ви хочете, щоб MSI/MSI‑X переривання доставлялися гостю чисто. Перенаправлення переривань допомагає тримати це під контролем і безпекою.
Без нього ви можете бачити попередження в dmesg, відступи або обмеження. Коли описують «джиттер» на пристроях passthrough, часто винні переривання.

3) ATS/PRI і сусіди: коли пристрої стають кмітливішими

Деякі пристрої можуть активніше брати участь у трансляції адрес (ATS) або запитувати сторінки (PRI). Теоретично це покращує продуктивність.
На практиці це збільшує площу поверхні для платформних особливостей. Якщо ви гонитеся за рідкісними IOMMU‑помилками під навантаженням, ці функції можуть бути релевантними.
Не потрібно вчити абревіатури напамʼять; потрібно розпізнавати шаблони і знати, куди дивитися.

4) Домени скидання і підтримка FLR

Function Level Reset (FLR) значно полегшує життєвий цикл passthrough.
Якщо ваш пристрій не може коректно скинутися, ви отримаєте класичний симптом: перший запуск працює, другий — відмовляє, поки не перезавантажите хост.
Це впливає на обидві платформи — Intel і AMD — тому що часто це обмеження самого пристрою, а не IOMMU.

5) Дозрілість прошивки: BIOS — частина вашого гіпервізора

На папері VT‑d і AMD‑Vi — обидва зрілі. На практиці якість прошивки варіюється від «міцно» до «хтось відправив в пʼятницю».
Плата може рекламувати підтримку IOMMU і все одно мати зламані IVRS/DMAR‑таблиці або сумнівні за замовчуванням налаштування.
Оновіть BIOS рано і ставтеся до release notes як до звітів інцидентів — бо це саме те, чим вони і є.

Продуктивність: де ховається накладна вартість

При passthrough сирий пропуск часто близький до голого металу. Вбивці — це:

Затримка і джиттер від обробки переривань, планування і невідповідності NUMA.
Накладні витрати на DMA‑мапінг, коли памʼять гостя фрагментована або робоче навантаження часто змінює відображення.
Неправильне розміщення NUMA: передача пристрою, звʼязаного з NUMA‑вузлом 1, гостю, привʼязаному до вузла 0 — це повільний фейсплант.
Hugepages проти звичайної памʼяті: hugepages зменшують тиск на TLB і можуть зменшити накладні витрати відображення для деяких навантажень.

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

Безпека та надійність: що ви отримуєте, коли все коректно

IOMMU — це межа безпеки. Без неї DMA‑здатний пристрій може читати/писати памʼять хоста напряму.
З нею пристрій обмежений відображенням, визначеним ядром/гіпервізором хоста.

Це важливо для:

Багатоорендних хостів (навіть «орендарів» в межах однієї компанії).
Недовірених драйверів у гостях (особливо GPU і нішеві акселератори).
Утримання від небажаної поведінки пристрою (помилки прошивки, зловмисний DMA тощо).

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

Одна цитата для чесності: Сподівання — не стратегія. — Рік Пітіно

Практичні завдання: команди, виводи та рішення (12+)

Це орієнтовано на Linux, бо саме там більшість VFIO/KVM passthrough живе і де ви будете налагоджувати о 02:00.
Команди запускаються на сучасних дистрибутивах; підлаштуйте імена пакетів під своє середовище.

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

cr0x@server:~$ lscpu | egrep -i 'Vendor ID|Model name|Virtualization|Flags'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU
Virtualization:        VT-x
Flags:                 ... vmx ...

Що це означає: «Virtualization: VT‑x» (Intel) або «AMD‑V» (AMD) повідомляє, що в CPU є віртуалізація. Це не доводить, що IOMMU увімкнено.

Рішення: Якщо віртуалізація відсутня — зупиніться. Ви не будете робити passthrough на цьому хості в жоден розумний спосіб.

Завдання 2: Підтвердити, що IOMMU увімкнено в ядрі (Intel VT-d)

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|VT-d' | head -n 30
[    0.612345] DMAR: IOMMU enabled
[    0.612678] DMAR: Host address width 46
[    0.613210] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.615432] DMAR: Interrupt remapping enabled

Що це означає: «DMAR: IOMMU enabled» — головна лінія. «Interrupt remapping enabled» — сильний знак, що у вас буде менше дивних кейсів з перериваннями.

Рішення: Якщо ви не бачите DMAR‑рядків — перевірте налаштування BIOS і параметри ядра (див. пізніші завдання). Не починайте налагодження VFIO, поки це не виправлено.

Завдання 3: Підтвердити, що IOMMU увімкнено в ядрі (AMD‑Vi)

cr0x@server:~$ dmesg | egrep -i 'AMD-Vi|IOMMU|IVRS' | head -n 40
[    0.501234] AMD-Vi: IOMMU performance counters supported
[    0.501567] AMD-Vi: Lazy IO/TLB flushing enabled
[    0.504321] ivrs: IOAPIC[4] not in IVRS table

Що це означає: Рядки AMD‑Vi вказують, що драйвер IOMMU від AMD активний. Попередження IVRS можуть бути нешкідливими або сигналом про проблеми прошивки залежно від серйозності.

Рішення: Якщо в логах повторюються скарги на IVRS/IOAPIC і passthrough нестабільний — оновіть BIOS і розгляньте іншу плату, перш ніж витрачати тиждень на налагодження.

Завдання 4: Перевірити командний рядок ядра (intel_iommu / amd_iommu)

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

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

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

Завдання 5: Підтвердити групи IOMMU і знайти «погане шарінг»

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | sed 's#.*/##' | sort | head
0000:00:01.0
0000:00:14.0
0000:00:14.2
0000:01:00.0
0000:01:00.1

Що це означає: Це виводить пристрої в групах IOMMU. Потрібно перевірити, до якої групи належить кожен пристрій, і чи ізольований ваш цільовий пристрій.

Рішення: Якщо ваша цільова GPU/NVMe/NIC ділиться групою з несумісними пристроями, змініть слот, плату або прийміть ризик ACS override.

Завдання 6: Надрукувати групи з людськими назвами

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; for d in $g/devices/*; do lspci -nns ${d##*/}; done; echo; done | sed -n '1,40p'
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1234] (rev 02)

Group 1
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678] (rev 02)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Що це означає: Шукаєте «лише функції GPU» в групі, а не GPU плюс SATA плюс USB плюс випадковий міст з друзями.

Рішення: Чисте групування? Далі з VFIO. Заплутане групування? Розгляньте інший PCIe‑слот (часто змінює root‑порт) або іншу материнську плату.

Завдання 7: Перевірити, чи пристрій підтримує сигнали скидання (FLR)

cr0x@server:~$ lspci -s 01:00.0 -vv | egrep -i 'Capabilities:|FLR|Reset' -n | head -n 20
45:Capabilities: [1b0] Vendor Specific Information: ID=0001 Rev=1 Len=024
78:Capabilities: [1e0] Device Serial Number 00-00-00-00-00-00-00-00
92:Capabilities: [250] Latency Tolerance Reporting
110:Capabilities: [300] Secondary PCI Express
132:Capabilities: [400] Physical Resizable BAR
160:Capabilities: [420] Data Link Feature

Що це означає: Не всі пристрої явно рекламують FLR у вигляді очевидного grep. Дехто покаже «Function Level Reset» прямо; інші — ні.

Рішення: Якщо ваша GPU погано скидається на практиці, плануйте помʼякшення: модулі vendor‑reset (де доступні), уникання патернів швидкого перезапуску або вибір іншої моделі GPU, відомої гарним скиданням.

Завдання 8: Визначити драйвер, який зараз звʼязаний з PCI‑пристроєм

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Якщо «Kernel driver in use» — це драйвер постачальника, ви ще не передали пристрій у VFIO.

Рішення: Для passthrough звʼяжіть його з vfio-pci на хості та тримайте консоль хоста на iGPU або окремій GPU.

Завдання 9: Привʼязати пристрій до vfio-pci (постійно через modprobe конфіг)

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

Що це означає: Ви кажете хосту привʼязати ці PCI‑ID до vfio‑pci на ранньому етапі завантаження. Оновлення initramfs гарантує дію.

Рішення: Якщо ви покладаєтеся на GPU для консолі хоста, не робіть цього. Використайте iGPU або серійний/IPMI. Інакше ви дуже чисто себе відключите.

Завдання 10: Підтвердити привʼязку vfio-pci після перезавантаження

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: «Kernel driver in use: vfio-pci» — це бажаний стан. «Kernel modules» можуть і досі перелічувати модулі вендора; це нормально.

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

Завдання 11: Перевірити наявність IOMMU‑faults та помилок DMA‑ремапінгу

cr0x@server:~$ sudo dmesg -T | egrep -i 'DMAR|IOMMU|fault|vfio|remapping' | tail -n 30
[Tue Feb  4 01:12:11 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Tue Feb  4 01:13:09 2026] DMAR: [DMA Read] Request device [01:00.0] fault addr 0x7f2b0000 [fault reason 05] PTE Read access is not set

Що це означає: DMA‑помилки вказують на проблеми відображення або поведінку пристрою, яка порушує поточні відображення. Іноді це неправильно налаштований драйвер гостя; іноді — платформні особливості.

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

Завдання 12: Підтвердити hugepages (гігієна затримок для гостей)

cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages:    1048576 kB
HugePages_Total:      256
HugePages_Free:       200
HugePages_Rsvd:        10
Hugepagesize:       2048 kB

Що це означає: Показує, чи зарезервовано явні hugepages. Багато затратно‑чутливих навантажень passthrough поводяться краще з передбачуваним бекінгом памʼяті.

Рішення: Якщо ви бачите «підвисання» під навантаженням у GPU‑VM або VM для обробки пакетів, hugepages — розумний наступний важіль після виправлення груп IOMMU і розміщення NUMA.

Завдання 13: Перевірити локальність NUMA для переданого пристрою

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/numa_node
1

Що це означає: Пристрій живе на NUMA‑вузлі 1. Якщо vCPU і памʼять гостя на вузлі 0 — ви платите за крос‑сокетні доступи.

Рішення: Прикріпіть vCPU і памʼять гостя до вузла пристрою там, де можливо. Якщо не можна — перегляньте, який слот використовує пристрій (деякі слоти мапляться на інші корні CPU).

Завдання 14: Дослідити топологію PCIe, щоб зрозуміти причини групування

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           +-14.0
           \-1c.0-[02]----00.0-[03]----00.0

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

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

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

cr0x@server:~$ lsmod | egrep 'vfio|kvm' | head
vfio_pci               65536  0
vfio_pci_core          90112  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   45056  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             409600  0

Що це означає: Ядро VFIO і IOMMU type1 завантажені. Якщо їх немає — ваш хост не готовий до passthrough, навіть якщо BIOS налаштовано.

Рішення: Завантажте модулі, виправте initramfs і підтвердіть, що конфіг ядра підтримує VFIO. Не налаштовуйте гість до тих пір, поки фундамент хоста не стабільний.

Завдання 16: Перевірити, чи ядро використовує перенаправлення переривань

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:' | head
[    0.615432] DMAR: Interrupt remapping enabled

Що це означає: На Intel це явно видно. На AMD ви можете побачити іншу формулювання. У будь‑якому разі шукаєте ознаки, що сучасна обробка переривань увімкнена.

Рішення: Якщо перенаправлення переривань вимкнено і ви бачите нестабільність або попередження безпеки — перевірте перемикачі BIOS повʼязані з VT‑d/AMD IOMMU і interrupt remapping, потім протестуйте знову.

Швидкий план діагностики

Коли passthrough ламається, ви не починаєте з переписування конфігурації QEMU. Ви починаєте з перевірки, чи платформа здатна бути коректною.
Ось потік «знайти вузьке місце швидко», який я використовую.

Спочатку: чи IOMMU реально увімкнено і нормальне?

Перевірте /proc/cmdline на предмет intel_iommu=on або amd_iommu=on.
Перевірте dmesg на «IOMMU enabled» і будь‑які скарги DMAR/IVRS.
Перевірте, що модулі VFIO завантажуються.

По‑друге: чи групи IOMMU прийнятні?

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

По‑третє: це помилка скидання/прошивки, а не «тонке налаштування VFIO»?

Працює перший запуск VM, але наступні — ні? Пахне проблемою скидання/FLR.
Повертаєте пристрій тільки після перезавантаження хоста? Це домен скидання.
Оновіть BIOS. Потім оновіть ядро. Потім протестуйте. Не міняйте 12 змінних одночасно.

По‑четверте: це NUMA/затримка переривань, що маскується під «повільний passthrough»?

Перевірте NUMA‑вузол пристрою та вирівняйте пінування VM.
Шукайте статус перенаправлення переривань і проблеми MSI/MSI‑X в логах.
Лише після цього: розгляньте hugepages, ізоляцію CPU і налаштування планувальника.

Жарт №2: IOMMU не «випав випадково». Воно дочекалося, поки ви будете впевнені.

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

1) «VFIO працює раз, потім чорний екран при другому завантаженні»

Симптом: Гість завантажується й використовує GPU один раз. Після вимкнення/перезапуску GPU ніколи не ініціалізується знову, поки хост не перезавантажити.

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

Виправлення: Віддавайте перевагу GPU, відомим дружнім до віртуалізації скиданням; спробуйте інший слот (змінює домен скидання); оновіть BIOS; розгляньте модуль‑workaround для скидання, якщо підходить; уникайте циклів швидкого перезапуску.

2) «Пристрій у величезній групі IOMMU з SATA/USB; не можна передати безпечно»

Симптом: Ваша GPU ділить IOMMU‑групу з контролером SATA і контролером USB чіпсету.

Корінь проблеми: Відсутність ACS‑ізоляції на відповідному downstream‑шляху; плата маршрутизувала кілька функцій за один міст; прошивка експонує грубе групування.

Виправлення: Переставте карту в слот, що корениться до CPU; відключіть непотрібні вбудовані пристрої; оберіть іншу материнську плату з кращою PCIe‑ізоляцією. Використовуйте ACS override лише якщо приймаєте ризики безпеки і стабільності.

3) «Високий пропуск, але жахлива затримка/джиттер»

Симптом: NVMe‑тести дають гарний пропуск, але в додатку стрибає затримка; фрейм‑тайми GPU нерівномірні; обробка пакетів NIC стрибкоподібна.

Корінь проблеми: NUMA‑невідповідність, проблеми з обробкою переривань, контенція на хості, відсутні hugepages.

Виправлення: Вирівняйте vCPU і памʼять гостя до NUMA‑вузла пристрою; переконайтеся, що перенаправлення переривань і MSI/MSI‑X працюють; ізолюйте CPU хоста для чутливих до затримки гостей; використайте hugepages.

4) «IOMMU увімкнено, але груп немає»

Симптом: dmesg згадує IOMMU, але /sys/kernel/iommu_groups порожній або відсутній.

Корінь проблеми: Ядро завантажилось без параметрів IOMMU; в BIOS вимкнено віртуалізацію; або мікс режимів ядра/завантаження (рідко, але буває).

Виправлення: Перевірте перемикачі BIOS (VT‑d/AMD IOMMU); перевірте /proc/cmdline; оновіть ядро; переконайтеся, що ви не працюєте на урізаному білді ядра.

5) «IOMMU‑помилки під навантаженням»

Симптом: DMAR/AMD‑Vi помилки зʼявляються в dmesg під інтенсивним I/O; гість зависає або пристрій відвалюється.

Корінь проблеми: Баги в прошивці платформи, нестабільне PCIe‑зʼєднання або погана взаємодія просунутих трансляційних функцій.

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

6) «Хост втрачає мережу або сховище при запуску VM»

Симптом: Запуск VM з passthrough змушує сервіси хоста померти.

Корінь проблеми: Ви передали не той пристрій (або правильний пристрій, але у тій же групі, що і критичні хост‑пристрої), бо групування було проігноровано.

Виправлення: Повторно перевірте групи IOMMU, привʼязуйте лише цільові PCI‑ID і тримайте критичні контролери хоста поза passthrough. Якщо не виходить — апаратне забезпечення не підходить для такого дизайну.

Три короткі історії з практики

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія хотіла GPU‑passthrough для кількох робочих станцій ML, що запускалися як VM.
План здавався простим: один хост на команду, одна GPU на VM, легке масштабування.
Закупівля привезла партію «готових до віртуалізації» машин, бо в специфікації CPU було згадано VT‑d або AMD‑Vi.

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

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

Вони врешті переставили GPU в інші слоти там, де можливо, а для частини хостів замінили модель материнської плати.
Урок не в «Intel vs AMD». Урок: список можливостей CPU — це не гарантія passthrough. Продукт — це плата.

Міні‑історія 2: Оптимізація, що обернулась проти

Інша організація запускала віртуалізований сховищний апаратний блок VM з переданим HBA і високопродуктивним NIC для реплікації.
Вони гналися за кількома відсотками пропуску і вирішили «оптимізувати», увімкнувши всі фічі продуктивності в BIOS: агресивні енергетичні налаштування, глибші C‑стани та деякі IOMMU‑перформанс‑перемикачі.

У синтетичному бенчмарку пропуск виріс. У продакшені затримка погіршилася.
Вікна реплікації почали пропускатися, і гірше: storage‑VM іноді логував I/O timeout під піковим навантаженням.
Нічого цілком не ламалося, тож розслідування стало дорожчим, бо виглядало як «мережа глючить».

Корінь — комбінація енергоменеджменту і затримки переривань, що погано взаємодіяли з passthrough NIC.
VCPU VM були закріплені на неправильний NUMA‑вузол відносно NIC, тож кожне переривання було фактично крос‑сокетною переговорами.
Вони оптимізували не ту метрику і застосували це до єдиної метрики, що важлива: затримки для користувача.

Відкат «оптимізацій», вирівнювання NUMA і консервативний енергопрофіль відновили стабільність.
Найсмішніше (сухим стилем) було те, що система спочатку була нормальною; їхній тріумф у бенчмарку створив інцидент.

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

Фінансова компанія мала кластер хостів віртуалізації з мішаними навантаженнями, включно з кількома VM з passthrough NIC для спеціального захоплення пакетів.
Спочатку вони ставилися до хостів passthrough як до «питомців» — ручне налаштування, любовні конфігурації і неможливі для відтворення.
Згодом вони втомилися від сюрпризів і стандартизували процес.

«Нудна практика» — це preflight‑чеклист, який виконували на кожному новому хості і після кожного оновлення BIOS:
підтвердити IOMMU, підтвердити перенаправлення переривань, дамп груп IOMMU, зняти знімок топології PCIe і зафіксувати відомі‑хороші параметри ядра.
Нічого гламурного. Просто дисципліна.

Потім один оновлення BIOS непомітно змінило порядок нумерації PCIe на частині машин.
Без preflight вони б виявили це під час продакшн‑вікна, коли пристрої приєдналися до інших груп і старі VFIO‑привʼязки захопили неправильний контролер.
Завдяки preflight вони спіймали це в стенді, підкоригували привʼязки і відправили без драм.

Система не стала швидшою. Вона стала передбачуваною. В операх це зазвичай краща угода.

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

Покроково: вибір апаратури для passthrough (щоб не купити сожаління)

Починайте з моделі материнської плати, а не з CPU. Перевіряйте, чи повідомляють люди про чисті групи IOMMU для ваших пристроїв.
Віддавайте перевагу слотам, кореневим для CPU, для пристроїв passthrough (GPU, NVMe‑адаптер, NIC). Слоти, кореневі для чіпсету, часто групуються агресивніше.
Уникайте платформ, що потребують ACS override для базової ізоляції. Якщо мусите його використовувати — документуйте прийняття ризику явно.
Плануйте доступ до консолі хоста: iGPU, BMC/IPMI або серійний порт. Не покладайтеся на передану GPU для доступу до хоста.
Залиште бюджет на оновлення прошивки: обирайте вендорів, які підтримують оновлення BIOS для стабільності, а не лише мікрокоду CPU.

Покроково: базова конфігурація хоста (Linux + KVM/VFIO)

Увімкніть VT‑d/AMD IOMMU в BIOS/UEFI. Також вмикайте будь‑який параметр «interrupt remapping», якщо він доступний.
Завантажтесь з intel_iommu=on iommu=pt або amd_iommu=on iommu=pt.
Підтвердіть у dmesg, що IOMMU увімкнено і немає серйозних помилок DMAR/IVRS.
Підтвердіть групи IOMMU; перевірте ізоляцію цільового пристрою.
Привʼяжіть цільові PCI‑ID до vfio-pci в initramfs.
Зафіксуйте CPU/памʼять VM на правильному NUMA‑вузлі, якщо затримання важливі.
Протестуйте життєвий цикл: старт VM, навантаження, вимкнення, повторний старт. Повторюйте, поки не набридне. Нудьга — це ціль.

Покроково: як вирішити між passthrough і паравіртуальними пристроями

Використовуйте virtio, коли можна (диск, мережа). Це простіше і часто «достатньо швидко».
Використовуйте passthrough, коли потрібно (функції NIC спеціальні, GPU для обчислень/графіки, драйвери вендора, що вимагають доступу до фізичної функції, HBA для сховищних апаратів).
Якщо сумніваєтеся, не передавайте критичні контролери хоста. Якщо ви передасте єдиний HBA з коренем ОС хоста, одна помилка — і вам потрібна віддалена перевстановлення.

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

1) Чи є Intel VT-d за своєю суттю стабільнішим за AMD‑Vi?

Не за своєю суттю. Стабільність здебільшого залежить від реалізації платформи: таблиць прошивки (DMAR/IVRS), топології PCIe і поведінки скидання пристроїв.
На сертифікованих серверних платформах обидва можуть бути дуже стабільними. На споживчих платах обидва можуть бути хаотичними — просто по‑різному.

2) Чому мої групи IOMMU «гірші» на одній материнській платі, ніж на іншій?

Тому що групування залежить від PCIe‑містів, комутаторів і підтримки ACS на шляху.
Плата, що прокладає кілька слотів за одним downstream‑мостом (без ACS), «склеїть» пристрої в одну групу.
Інша плата з більшою кількістю root‑портів або кращою ACS‑ізоляцією дасть чистіші групи.

3) Чи варто використовувати ACS override?

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

4) Чи знижує `iommu=pt` ізоляцію гостя?

Зазвичай це налаштовує ідентичні/pass‑through відображення для DMA хоста для продуктивності, при цьому зберігається трансляція для пристроїв, привʼязаних до гостей.
Це часто використовується на хостах віртуалізації. Якщо ви налагоджуєте або валідуєте сувору ізоляцію, можете протестувати без нього.

5) Чому GPU passthrough відмовляє після перезавантаження VM?

Зазвичай через поведінку скидання: GPU не скидається чисто (немає робочого FLR, або скидання не поширюється), залишаючи його в поганому стані.
Іноді це також взаємодія драйвера/прошивки. Надійне виправлення — вибір апаратури, відомої дружньою до скидань, плюс правильна топологія.

6) Чи простіше SR‑IOV на платформах Intel чи AMD?

Успіх SR‑IOV сильно залежить від моделі/прошивки NIC, зрілості драйвера і коректності IOMMU.
І Intel, і AMD платформи можуть добре запускати SR‑IOV. «Простіший» досвід зазвичай дають корпоративні NIC і серверні плати з витриманою BIOS.

7) Який найшвидший спосіб дізнатися, чи passthrough буде безболісним на хості?

Перевірте групи IOMMU і протестуйте цикли перезавантаження. Якщо пристрій чисто ізольований і ви можете багаторазово перезавантажувати гостя без перезавантаження хоста — ви на 80% шляху.
Залишок 20% — це тюнінг продуктивності і робота з крайовими випадками.

8) Чи важливі версії ядра для VT-d/AMD‑Vi passthrough?

Так. IOMMU, VFIO і PCIe‑quirks отримують виправлення з часом. Якщо ви женетеся за рідкісними помилками або проблемами скидання, новіші ядра можуть допомогти.
Просто оновлюйте методично: одна зміна за раз і план відкату.

9) Чи варто передавати NVMe‑диск?

Це може бути відмінно для продуктивності і для сховищних апаратних VM, які хочуть прямий контроль.
Але NVMe іноді ділить групи IOMMU з іншими пристроями на деяких платах, і потрібно уникати передачі пристроїв, необхідних хосту для завантаження.

10) Чи обрати Intel або AMD для складання під Proxmox/KVM passthrough?

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

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

Якщо ви вирішуєте між Intel VT-d і AMD‑Vi для passthrough, не робіть це як вибір бренду.
Розглядайте це як проблему ланцюга постачання: обирайте платформу, де топологія плати і дозрілість прошивки відповідають вашим потребам ізоляції.

Для нових збірок: скоротіть список плат, потім перевірте повідомлену якість груп IOMMU для ваших конкретних типів пристроїв і слотів.
Для існуючих хостів: виконайте перелік груп, підтвердьте перенаправлення переривань і протестуйте цикли перезавантаження під навантаженням.
Для продакшн‑розгортань: стандартизujte preflight‑чеклист, контролюйте оновлення BIOS і ядра, і документуйте, які слоти «пасструх‑безпечні».

Успіх‑умова не «максимальний пропуск». Це «жодних сюрпризів при перезавантаженні». Коли ви досягнете цього, і VT‑d, і AMD‑Vi виглядають дуже добре.

Схожі статті

MSI/MSI‑X і перенаправлення переривань: 5‑хвилинне виправлення випадкових зависань ВМ