IOMMU пояснено: єдиний перемикач у BIOS, що робить (або ламає) GPU passthrough

Що таке IOMMU насправді (і чому для GPU passthrough це необхідно)

IOMMU — це блок керування пам’яттю для пристроїв. CPU має MMU, який транслює віртуальні адреси у фізичні,
забезпечуючи ізоляцію між процесами. IOMMU робить подібну трансляцію та ізоляцію, але для DMA (Direct Memory Access)
запитів від PCIe-пристроїв, таких як GPU, мережеві картки, NVMe-контролери та HBA.

Без IOMMU пристрій, що виконує DMA, може фактично сказати: «Я хочу читати/записувати фізичну пам’ять за адресою X».
Якщо пристрій має баг, неправильно налаштований або скомпроментований, він може перезаписати ядро хосту, пам’ять іншої VM або сторінку з секретами.
З IOMMU хост налаштовує таблицю трансляції так, щоб пристрій бачив лише ту пам’ять, яку хост має намір дозволити.

GPU passthrough в одному реченні

GPU passthrough означає, що драйвер у VM спілкується з реальною GPU по PCIe так, ніби вона належить гостьовій ОС, поки гіпервізор використовує IOMMU-трансляції
для обмеження DMA цього пристрою пам’яттю цієї VM.

Чому «воно завантажується» — не доказ

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

Шари, які ви фактично дебагуєте

• ПЗУ: перемикачі BIOS/UEFI (VT-d / AMD-Vi), SR-IOV, “Above 4G decoding”, “Resizable BAR”.
• Ядро: IOMMU увімкнено, перенаправлення переривань (interrupt remapping) увімкнено, режим трансляції DMA (strict vs lazy).
• Топологія PCIe: root-порти, ACS і чи потрапляють пристрої в роздільні IOMMU-групи.
• Прив’язка драйверів: хостовий драйвер проти vfio, хто захоплює GPU під час завантаження.
• Конфігурація гіпервізора: QEMU/KVM аргументи, OVMF проти SeaBIOS, тип машини (q35 має значення).

Якщо ви ставитеся до IOMMU як до «якоїсь віртуалізаційної штуки», ви й далі будете робити культові зміни налаштувань, поки щось випадково не запрацює… а потім перестане.
Ставтеся до нього як до примітива ізоляції з очевидними станами — і отримаєте передбачуваний результат.

Цікаві факти та історія, яку можна використати на зустрічах

Ось конкретні, не-тривіальні пункти, які допомагають пояснити, чому IOMMU з’явився і чому його так легко неправильно налаштувати:

1. DMA передує сучасній віртуалізації на десятиліття. Ранні високопродуктивні пристрої використовували DMA, щоб уникнути копіювання CPU — добре для швидкості, проблематично для ізоляції.
2. IOMMU — відповідь на хаос спільної шини. Коли PCI і пізніше PCIe розповсюдилися, модель «довіряй кожному пристрою» стала загрозою для безпеки та надійності.
3. Intel називає це VT-d; AMD — AMD-Vi. Різне брендування, одна ідея: перенаправляти DMA пристроїв через таблиці трансляції.
4. Сучасні ОС все частіше припускають наявність IOMMU. Це не лише для VM; використовується також для жорсткішого ядра та безпечного призначення пристроїв.
5. Перенаправлення переривань стало частиною історії. Це не лише DMA. Пристрої також генерують переривання; їхнє перенаправлення допомагає запобігти певним класам помилок маршрутизації або ін’єкції переривань.
6. ACS (Access Control Services) — не «приємна штука». ACS впливає на те, як трафік PCIe ізольований між кінцевими точками; слабкий ACS часто означає «усе в одній IOMMU-групі».
7. Постачальники GPU спочатку не були у захваті. Ранній passthrough був примхливим, тому що споживчі GPU і драйвери не розроблялися з думкою про призначення у VM.
8. Above 4G decoding важливий через великий запит GPU на адресний простір. Великі BAR-мапінги і сучасні платформи штовхають вас до можливостей адресного простору, які старі дефолти не обробляють добре.

Перемикач у BIOS/UEFI: назви, пастки та що насправді означає “увімкнено”

Найдорожча помилка при GPU passthrough — припускати, що напис у BIOS відповідає фактичному стану апаратури.
На багатьох системах потрібно увімкнути кілька опцій, і назви відрізняються в залежності від виробника і покоління материнської плати.
Головна вимога: CPU + чипсет мають експонувати IOMMU, а прошивка не повинна його відключати.

Як називається налаштування

• Intel: “Intel VT-d,” “VT-d,” “IOMMU,” іноді “Directed I/O.”
• AMD: “SVM” (CPU virtualization) — це не IOMMU; вам потрібне “IOMMU,” “AMD-Vi,” іноді “PCIe ARI support.”
• Серверні платформи: Можна також побачити “Interrupt Remapping,” “DMA Protection,” “PCIe ACS,” “SR-IOV.”

Пастки в BIOS, що здаються не пов’язаними, але є важливими

• CSM vs чистий UEFI: Багато налаштувань passthrough працюють краще з OVMF (UEFI) і вимкненим CSM.
• Above 4G decoding: Часто потрібне для сучасних GPU, особливо якщо ви передаєте кілька пристроїв або використовуєте великі BAR-функції.
• Resizable BAR: Може змінювати розміри BAR і поведінку мапінгу. Іноді корисно, іноді дестабілізує. Не вмикайте його просто «через продуктивність».
• Розщеплення слотів PCIe (bifurcation): Може змінити топологію; топологія змінює IOMMU-групи.

Жарт №1: BIOS-меню — єдине місце, де “Enabled” може означати “можливо, залежно від настрою і мікрокоду.”

Цитата, щоб тримати команду чесною

Надія — не стратегія. — перефразована ідея, часто цитована в інженерних/операційних колах

Переклад для IOMMU: не «надійтеся», що воно увімкнено, бо ви колись щось перемикали. Перевіряйте з боку ОС.

IOMMU-групи: межа, що вирішує, чи можна ізолювати GPU

Навіть за умови увімкненого IOMMU ви можете залишитися в ситуації, коли ваша GPU ділиться IOMMU-групою з іншими пристроями, які мають залишатися на хості
(наприклад USB-контролер для клавіатури або SATA-контролер з диском завантаження хоста). IOMMU-групи представляють
найменші одиниці ізоляції, які платформа може безпечно забезпечити для DMA.

Чому групи існують

Пристрої за спільним upstream PCIe-бриджем можуть бачити трафік один одного, якщо платформа не підтримує ACS і належну ізоляцію.
Ядро групує такі пристрої разом, бо не може гарантувати розділення. Передача одного пристрою означає передачу всієї групи.

Що ви хочете бачити

• GPU (і її функцію HDMI audio) в IOMMU-групі, що містить тільки ці функції.
• NIC та контролери зберігання в окремих групах, якщо ви не плануєте передавати їх спеціально.
• Мінімальну поведінку «все в групі 0»; це зазвичай сигналізує, що IOMMU не увімкнено або не виставлено правильно.

ACS override: спокусливий хак

На деяких споживчих платах ви можете змусити ядро розділити групи за допомогою параметра ACS override. Це часто подається як магічне рішення.
Це не магія; це ви кажете ядру вдавати, що ізоляція існує, навіть якщо апаратно її немає повною мірою.

Використовуйте ACS override лише коли розумієте ризик: ви можете отримати функціональний passthrough, але DMA-ізоляція може бути слабшою, ніж ви думаєте.
Для домашньої лабораторії це прийнятно. Для всього, що має справу з продакшн-даними — це питання управління ризиками.

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

Це послідовність «у мене 20 хвилин до кінця вікна змін». Не імпровізуйте. Перевіряйте ці кроки в порядку; кожен крок відкидає певний клас проблем.

Спочатку: доведіть, що IOMMU реально увімкнено

• Перевірте параметри завантаження ядра і dmesg на предмет ініціалізації IOMMU.
• Підтвердіть наявність таблиць DMAR (Intel) або AMD-Vi (AMD).
• Підтвердіть статус перенаправлення переривань, якщо вам важлива стабільність і безпека.

Друге: перевірте IOMMU-групи та топологію

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

Третє: підтвердіть прив’язку драйверів і володіння VFIO

• Переконайтеся, що хост не прив’язав GPU до nouveau/nvidia/amdgpu.
• Прив’язуйте функції GPU до vfio-pci рано під час завантаження; не покладайтеся на «відв’язку пізніше», якщо вам не подобаються помилки.
• Підтвердіть наявність вузлів /dev/vfio/* і їх відповідність ID груп.

Четверте: перевірте прошивку VM, тип машини та поведінку скидання

• Використовуйте OVMF (UEFI) і q35, якщо немає причин інакше.
• Якщо GPU не скидається коректно між перезапусками VM, плануйте vendor-reset (де застосовно) або перезавантаження хоста.
• Перевірте проблеми з ROM, вибором primary GPU і маршрутизацією консолі.

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

Наступні завдання навмисно практичні. Кожне містить: команду, типовий вивід, що він означає,
і рішення, яке слід ухвалити далі. Якщо ви робите GPU passthrough без виконання цих кроків, ви працюєте на основі відчуттів.

Завдання 1: Визначте виробника CPU і прапори віртуалізації

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

Значення: VT-x (Intel) або SVM (AMD) — це віртуалізація CPU, а не IOMMU. Проте якщо цього немає, KVM не запрацює.

Рішення: Якщо відсутня підтримка віртуалізації CPU, виправте налаштування в BIOS. Поверніться після цього.

Завдання 2: Підтвердіть, що IOMMU увімкнено в параметрах командного рядка ядра

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

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

Рішення: Якщо параметра нема — додайте через GRUB/systemd-boot. Якщо є — переходьте до перевірки dmesg.

Завдання 3: Перевірте dmesg на предмет ініціалізації DMAR/AMD-Vi

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 25
[    0.012345] DMAR: IOMMU enabled
[    0.012678] DMAR: Host address width 39
[    0.013000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.013250] DMAR: Queued invalidation will be enabled to support IOMMU
[    0.013500] DMAR: Intel(R) Virtualization Technology for Directed I/O

Значення: Це ядро повідомляє, що воно знайшло таблиці і увімкнуло DMA remapping.

Рішення: Якщо бачите помилки типу “IOMMU disabled” або нічого — зупиніться. Поверніться в BIOS/UEFI і перевірте режим завантаження.

Завдання 4: Перевірте статус перенаправлення переривань (stability/security)

cr0x@server:~$ dmesg | egrep -i 'remapping|x2apic|IR' | head -n 30
[    0.020000] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.020500] DMAR-IR: Queued invalidation will be enabled

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

Рішення: Якщо перенаправлення вимкнено через баги прошивки, розгляньте оновлення BIOS або інші параметри ядра. У регульованому середовищі відсутність remapping — це ризик, а не дрібниця.

Завдання 5: Перелічіть PCI-пристрої і знайдіть функції GPU

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|audio|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)

Значення: Зазвичай GPU має дві функції: графіку й HDMI/DP аудіо. Ви передаєте обидві.

Рішення: Запишіть PCI-адреси (01:00.0 і 01:00.1) і vendor:device ID (10de:1e87, 10de:10f8) для прив’язки vfio-pci.

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

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:"; ls -l "$g/devices"; done | sed -n '1,80p'
IOMMU Group 12:
total 0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:01:00.1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1

Значення: Група 12 містить лише GPU і її аудіофункцію. Так виглядає «добре».

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

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

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:3fdd]
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb

Значення: Хост захопив GPU драйвером nouveau. VFIO навряд чи візьме його пізніше коректно.

Рішення: Забороніть хостову прив’язку (blacklist драйверів) або прив’яжіть до vfio-pci рано. Не намагайтеся «просто відв’язати» в продакшні, якщо вам не подобаються несподіванки.

Завдання 8: Прив’яжіть GPU до vfio-pci через опції modprobe

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1
EOF

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_modeset
EOF

Значення: Ви повідомляєте ядру прив’язувати ці ID пристроїв до vfio-pci і не дозволяти типовим GPU-драйверам їх захоплювати.

Рішення: Перебудуйте initramfs (наступне завдання), щоб це застосовувалося рано, потім перезавантажтеся.

Завдання 9: Перебудуйте initramfs, щоб прив’язка vfio відбувалася при завантаженні

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.5.0

Значення: Ваш initramfs тепер включає оновлені опції модулів/blacklist, що впливає на ранню прив’язку пристроїв.

Рішення: Перезавантажтеся і перевірте lspci -nnk, щоб підтвердити, що vfio-pci володіє GPU.

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

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:3fdd]
	Kernel driver in use: vfio-pci
	Kernel modules: nouveau, nvidiafb

Значення: Ідеально. Список модулів може все ще згадувати потенційні модулі; ключовий рядок — «Kernel driver in use».

Рішення: Продовжуйте до конфігурації VM. Якщо драйвер не vfio-pci, у вас все ще є гоночна умова прив’язки (часто initramfs не оновлено або вказані неправильні ID).

Завдання 11: Підтвердіть наявність VFIO-пристроїв для групи

cr0x@server:~$ ls -l /dev/vfio/
total 0
crw------- 1 root root 244,   0 Feb  4 09:15 12
crw------- 1 root root  10, 196 Feb  4 09:15 vffo

Значення: Числовий вузол (12) відповідає IOMMU групі 12. Так VFIO забезпечує правило «всі пристрої групи переміщуються разом».

Рішення: Якщо вузол групи відсутній — VFIO не налаштовано або IOMMU не працює так, як ви думаєте. Поверніться до Завдань 2–6.

Завдання 12: Перевірте, чи GPU є завантажувальним VGA-пристроєм (може ускладнити ситуацію)

cr0x@server:~$ lspci -vv -s 01:00.0 | egrep -i 'Kernel driver|VGA|boot'
VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080] (rev a1)
	Kernel driver in use: vfio-pci
	Capabilities: [60] Power Management version 3
	Flags: bus master, fast devsel, latency 0, IRQ 16

Значення: На деяких системах ви побачите «Boot VGA» у флагах для первинної GPU. Якщо ваша passthrough GPU також є консоллю хоста — це додає роботи.

Рішення: Віддавайте перевагу iGPU або дешевому другому GPU для консолі хоста. Якщо не можете — доведеться керувати framebuffer/консоллю і можливо ROM-особливостями.

Завдання 13: Підтвердіть наявність прискорення KVM

cr0x@server:~$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

Значення: KVM доступний. Якщо /dev/kvm відсутній, ви отримаєте жахливу продуктивність і дивну поведінку таймінгів.

Рішення: Виправте підтримку віртуалізації CPU і модулі KVM перед тим, як звинувачувати VFIO.

Завдання 14: Швидко виявити співмешкання в групі для конкретного пристрою

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:01:00.0/iommu_group
/sys/kernel/iommu_groups/12

Значення: Це канонічне відображення групи. Воно зручне для скриптів і знімає здогадки.

Рішення: Якщо в групі є інші пристрої, вирішіть, чи можете їх також передати. Якщо ні — змініть топологію (слот/bifurcation) перед хакерськими змінами ядра.

Завдання 15: Перевірте, чи IOMMU «увімкнено», але фактично обхідне

cr0x@server:~$ dmesg | egrep -i 'iommu.*(pt|passthrough)|DMA' | head -n 20
[    0.050000] DMAR: IOMMU enabled
[    0.050500] DMAR: Default domain type: Passthrough (set via iommu=pt)

Значення: iommu=pt нормальний для хоста: він знижує накладні витрати для хостових пристроїв. Пристрої, призначені для VFIO, все одно отримують ізольовані домени.

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

Завдання 16: Перегляньте лог QEMU/libvirt на помилки при підключенні VFIO

cr0x@server:~$ sudo tail -n 60 /var/log/libvirt/qemu/win11-gpu.log
2026-02-04T09:21:10.123456Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0,id=hostdev0: vfio 0000:01:00.0: failed to setup container for group 12: Failed to set iommu for container: Operation not permitted
2026-02-04T09:21:10.123789Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0,id=hostdev0: failed to initialize VFIO device

Значення: Це проблема з правами / контейнером / володінням групою (або відсутністю можливості в рантаймі).

Рішення: Запускайте QEMU з відповідними привілеями (libvirt це робить), перевірте права на групи vfio і перевірте, чи ви не перебуваєте в непривілейованому контейнері, що намагається зробити passthrough.

Жарт №2: Помилки VFIO — як печеньки з передбаченнями: криптичні, трохи звинувачувальні і завжди приходять прямо перед тим, як ви хочете йти додому.

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

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

Середня компанія підняла тимчасовий хост для GPU-віртуалізації, щоб прискорити чергу машинного навчання. Він працював тиждень.
Потім рутинне перезавантаження підтримки перетворилося на південний день простою для ML-пайплайнів.

Припущення: «Ми увімкнули віртуалізацію в BIOS, тож passthrough покрито». Вони увімкнули VT-x, але не VT-d.
Хост все ще завантажувався, VM теж, і GPU виглядала в конфігурації VM — поки VFIO не спробував реально приєднатися.
Після перезавантаження GPU перерахувалася інакше (змінюється тренування слота), і тепер VM впала з помилкою групи VFIO/container.

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

Виправлення було нудним: увімкнути VT-d, оновити BIOS до стабільної ревізії і написати preflight-скрипт, що grep-ить dmesg на DMAR/AMD-Vi перед тим, як дозволяти GPU-навантаження на вузлі.
Також оновили чек-лист, щоб «віртуалізація увімкнена» стала двома явними перевірками: віртуалізація CPU і віртуалізація IOMMU.

Коротка історія 2: Оптимізація, що відкотилася

Інший відділ хотів витиснути трохи більше пропускної здатності з GPU VM. Хтось запропонував увімкнути Resizable BAR і переключити всі опції PCIe, що звучать як «продуктивність»: Above 4G decoding, ReBAR, агресивні ASPM-настройки і нову схему bifurcation слотів.
Бенчмарки для однієї VM трохи покращилися.

Потім почалися дивні речі: переривчасті помилки завантаження VM, випадкові зависання хоста під важким GPU-DMA і патерн, де друга VM після перезавантаження не стартувала, а перша — так.
Спочатку пахло драйверною проблемою, поки не стало очевидно інше.

Справжня проблема була в тому, що топологія і групи змінилися. Зміна bifurcation перемістила пристрої за інші бриджі, змінивши IOMMU-групи.
Їхня автоматизація все ще прив’язувала старі ID пристроїв, але групування стало грубшим і включило USB-контролер, потрібний хосту.
Іноді призначення груп проходило «безпечним» чином, іноді ні — залежно від порядку нумерації і поведінки прошивки.

Відкат виправив це миттю. Вони залишили Above 4G decoding (потрібне), відклали ReBAR і почали ставитися до топології PCIe як до змін, що керуються процесом, з чек-листом регресій: перевірити групи, перевірити прив’язку VFIO, перевірити старт/зупинку VM, перевірити поведінку ресету.

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

Команда фінансових послуг експлуатувала GPU passthrough на невеликому пулі хостів для аналітики. Нічого надзвичайного, але контроль змін був суворий. У них був preflight-runbook, що виглядав майже смішно простим: підтвердити IOMMU увімкнено, підтвердити незмінність груп, підтвердити прив’язку VFIO, підтвердити, що тестова VM може стартувати і зупинятися двічі.

Було заплановано оновлення прошивки як частину циклу безпеки. Нотатки виробника згадували «покращену сумісність PCIe».
Команда ставилася до цієї фрази як до потенційної проблеми. Вони відкачали одну хост-машину, оновили її і запустили повний preflight.

Preflight виявив, що після оновлення за замовчуванням було відключено перенаправлення переривань (прошивка скинула налаштування).
Все ще «працювало», але в логах ядра видно погіршення у DMA/обробці переривань. Вони відкотили прошивку на цьому хості,
а потім повторно застосували оновлення з явним контролем налаштувань BIOS і збереженими скріншотами в записі зміни.

Рятівна частина була не в героїці. Вони не виявили регресію під час квартального піку. Вони виявили її на відкачаному вузлі, з часом і доказами.

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

1) «IOMMU не виявлено» або відсутні рядки DMAR/AMD-Vi у dmesg

Симптом: VFIO attach не вдається; у dmesg немає DMAR/AMD-Vi.

Корінна причина: IOMMU вимкнено в BIOS/UEFI, або відсутні/ігноруються параметри завантаження ядра, або ви завантажуєтесь у режимі, що приховує можливості.

Виправлення: Увімкніть VT-d/AMD-Vi, підтвердіть параметри ядра, оновіть прошивку, якщо таблиці DMAR пошкоджені. Перевірте за Завданням 3.

2) GPU ділить IOMMU-групу з SATA/USB/NIC, які потрібні на хості

Симптом: Ви не можете передати GPU без передачі інших критичних пристроїв.

Корінна причина: Топологія PCIe + відсутність ACS-ізоляції; на споживчих платах пристрої часто групуються агресивно.

Виправлення: Спробуйте інший PCIe-слот, відключіть/увімкніть вбудовані пристрої, змініть bifurcation, оновіть BIOS. Останній захід: ACS override з очима відкритими.

3) VM завантажується, але продуктивність жахлива; незвично використання GPU

Симптом: VM повільна; кадри йдуть нерівно; обчислювальні задачі підтормовують.

Корінна причина: KVM не активний, або VM використовує емульовані пристрої, або проблеми з прив’язкою CPU/NUMA — не сам IOMMU.

Виправлення: Підтвердіть /dev/kvm, використовуйте virtio-пристрої, q35 + OVMF, і перевірте розміщення NUMA відносно кореневого комплексу PCIe GPU.

4) VM стартує один раз, але після вимкнення знову не стартує без перезавантаження хоста

Симптом: Перше приєднання працює; наступні приєднання не вдаються; GPU виглядає “завислим”.

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

Виправлення: Використовуйте vendor-reset де підтримується, передавайте всі функції, уникайте прив’язки хостового драйвера взагалі і плануйте перезавантаження хоста, якщо потрібно.

5) Чорний екран у VM попри успішний VFIO attach

Симптом: VM працює, але немає виводу дисплея з переданої GPU.

Корінна причина: Неправильна прошивка VM (SeaBIOS vs OVMF), відсутній ROM GPU, плутанина з primary GPU або вивід дисплея спрямований на інший порт.

Виправлення: Переключіться на OVMF, використовуйте q35, розгляньте вказання ROM-файлу за потреби, і переконайтеся, що монітор підключено до переданої GPU.

6) VFIO «failed to set iommu for container: Operation not permitted»

Симптом: У логах libvirt/QEMU помилки прав/контейнера.

Корінна причина: Спроба passthrough з непривілейованого контейнера, неправильні права пристроїв або неправильна модель безпеки libvirt.

Виправлення: Запускайте гіпервізор на хості, а не в непривілейованому контейнері; перевірте права /dev/vfio; використовуйте libvirt-managed QEMU з потрібними привілеями.

7) Ви увімкнули «SVM» на AMD і подумали, що це IOMMU

Симптом: Віртуалізація CPU працює; IOMMU — ні.

Корінна причина: SVM — це віртуалізація CPU; AMD-Vi — це IOMMU. Різні перемикачі.

Виправлення: Увімкніть AMD-Vi/IOMMU явно і перевірте dmesg на AMD-Vi.

8) ACS override «вирішує» групування, але вводить нестабільність або ризик

Симптом: Після ACS override групи виглядають ідеально, але з’являються рідкісні зависання хоста або зауваження на аудиті безпеки.

Корінна причина: Ви змусили ядро розділити групи далі, ніж апаратна ізоляція це гарантує.

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

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

Покроково: до першого успішного GPU passthrough (відтворювано)

1. ПЗУ: Увімкніть VT-d (Intel) або AMD-Vi/IOMMU (AMD). Увімкніть Above 4G decoding. Віддавайте перевагу чистому UEFI-завантаженню.
2. Параметри ядра: Додайте intel_iommu=on або amd_iommu=on. За потреби додайте iommu=pt.
3. Перезавантаження і перевірка: Використайте dmesg, щоб підтвердити, що DMAR/AMD-Vi увімкнено і немає очевидних помилок IOMMU.
4. Виявлення пристроїв: Використайте lspci -nn, щоб зафіксувати ID і адреси GPU та аудіофункції.
5. Перевірка груп: Переконайтесь, що функції GPU ізольовані у власній IOMMU-групі.
6. Прив’язка до vfio-pci рано: Налаштуйте IDs для vfio-pci і заблокуйте хостові GPU-драйвери; перебудуйте initramfs.
7. Перезавантаження і підтвердження прив’язки: lspci -nnk має показати vfio-pci для функцій GPU.
8. Конфігурація VM: Використовуйте q35 + OVMF. Передавайте обидві функції GPU. Для диска та мережі віддавайте перевагу virtio.
9. Тест життєвого циклу: Запустіть VM, прогрійте навантаження, вимкніть VM, запустіть знову. Повторіть. Ви тестуєте поведінку скидання, а не лише перший запуск.
10. Оперціоналізація: Напишіть preflight-перевірки (IOMMU увімкнено, групи стабільні, vfio-прив’язка вірна) і запускайте їх після оновлень прошивки/ядра.

Чек-лист для управління змінами (бо оновлення прошивки — хаос)

• Перед зміною: збережіть dmesg рядки IOMMU і перелік IOMMU-груп для GPU.
• Перед зміною: збережіть lspci -nnk для функцій GPU (який драйвер у використанні).
• Після зміни: повторіть ті самі команди; порівняйте виводи.
• Після зміни: запустіть/зупиніть тестову VM двічі; підтвердіть відсутність регресій.
• Якщо групи змінилися: розглядайте це як зміну топології і перевірте безпеку перед відновленням продакшн-навантажень.

Коли варто зупинитися і купити краще обладнання

• Ваша GPU ділить групу з критичними хост-пристроями і ви не можете змінити топологію, щоб її ізолювати.
• Вам потрібні суворі гарантії ізоляції, і ви покладаєтесь на ACS override, щоб «зробити групи гарними».
• Вам потрібна надійна поведінка ресету і ваше поєднання GPU/плати цього не дає без перезавантажень хоста.

Питання та відповіді (FAQ)

1) Чи IOMMU лише для віртуалізації?

Ні. Воно також використовується для ізоляції DMA і жорсткішого ядра на bare metal. Віртуалізація — лише найбільш видимий випадок застосування.

2) У чому різниця між VT-x і VT-d?

VT-x — це віртуалізація CPU (ефективне виконання коду гостя). VT-d — це IOMMU (перенаправлення DMA пристроїв). Для безпечного PCI passthrough потрібен VT-d.

3) На AMD чи «SVM» те саме, що AMD-Vi?

Ні. SVM — це віртуалізація CPU. AMD-Vi (часто позначається як IOMMU) потрібен для passthrough.

4) Чому треба також передавати аудіофункцію GPU?

Бо це зазвичай окрема PCI-функція в тому ж пакеті пристрою. Залишивши її на хості ви можете порушити поведінку ресету або викликати конфлікти драйверів у гості.

5) Чи IOMMU-групи — це обмеження Linux?

Групування відображає апаратні межі ізоляції (бриджі, можливості ACS). Linux консервативний: він не обіцяє ізоляцію, яку не може забезпечити.

6) Чи завжди слід використовувати iommu=pt?

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

7) Чи робить ACS override passthrough «безпечним»?

Воно може зробити працюючим. «Безпека» залежить від того, яку ізоляцію апаратно надає ваша платформа. Для продакшну або моделей з мульти-орендарністю уникайте на нього покладатися.

8) Моя VM працює доти, поки я не перезавантажу її. Чому?

Швидше за все проблема зі скиданням пристрою. Багато GPU не скидаються коректно через FLR у всіх сценаріях. Може знадобитися vendor-reset, інше обладнання або перезавантаження хоста між призначеннями.

9) Чи потрібен мені UEFI (OVMF) у VM?

Для багатьох сучасних GPU і Windows-гостей — так. OVMF + q35 зменшує дивні legacy VGA-шляхи і загалом поводиться краще для passthrough.

10) Чи можна запускати GPU passthrough зсередини контейнера?

На практиці GPU passthrough — це завдання рівня хоста. Непривілейовані контейнери зазвичай не мають прав і управління пристроями, необхідних для VFIO.

Висновок: наступні кроки, що справді дають результат

IOMMU — це не «фіча». Це контракт, що робить призначення пристроїв передбачуваним. Якщо ви хочете, щоб GPU passthrough був стабільним, перестаньте ставитися до налаштування BIOS як до чекбоксу і почніть розглядати його як залежність, яку треба постійно перевіряти.

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

1. Запустіть Завдання 2–6 на вашому хості і збережіть виводи як базову лінію (командний рядок ядра, dmesg рядки IOMMU, перелік IOMMU-груп).
2. Прив’яжіть GPU до vfio-pci рано (Завдання 7–10). Якщо ви все ще відв’язуєте на льоту — ви вибираєте крихкість.
3. Протестуйте життєвий цикл VM двічі (завантаження → навантаження → вимкнення → завантаження). Якщо працює лише раз — у вас демо, а не система.
4. Якщо групи «потворні» — спочатку виправляйте топологію. Якщо мусите використовувати ACS override — документуйте ризик і тримайте це поза середовищами зі строгими вимогами ізоляції.

Критерій успіху — нудний: стабільні групи, передбачувана прив’язка, відтворювані старти/зупинки VM. Коли стає нудно — ви все зробили правильно.