Групи IOMMU — пастка: як отримати чистий passthrough GPU/NVMe без сліз

Що таке групи IOMMU насправді (і чому вони заважають)

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

Ключовий момент — «не можна ізолювати». Межа групи визначається не вашими відчуттями, не написом на слоті материнської плати й не тим, скільки коштував GPU. Вона визначається топологією PCIe і поведінкою Access Control Services (ACS) у свічах/мостах між пристроєм і root-портом CPU. Якщо ACS не дає правильної ізоляції (або не заявлено про неї), ядро не буде прикидатися, що вона є.

Практичний наслідок

Чистий passthrough означає, що пристрій, який ви хочете — GPU або NVMe — опиняється в IOMMU групі без нічого зайвого, що вам потрібно. Ідеально: GPU і його аудіофункція разом, можливо USB-контролер, якщо ви свідомо його туди поставили, і все. Якщо ваш GPU ділить групу з контролером SATA, мережею та половиною чипсету, це не «GPU passthrough». Це «надія як сервіс».

Дві хибні ментальні моделі, що призводять до більшості проблем

• «Групи IOMMU фіксує ОС.» ОС звітує про те, що відкриває апаратне забезпечення й прошивка. Ви не можете компенсувати відсутність ACS у дешевому downstream-свічі налаштуваннями.
• «Якщо воно завантажується, то безпечно.» Безпека тут — це ізоляція DMA і перенаправлення переривань під навантаженням, при гарячих ресетах і відновленні після помилок. Завантаження нічого не доводить.

Гострий кінець: патч ACS override

На багатьох споживчих платформах люди «виправляють» погані групування IOMMU, змушуючи поведінку ACS через параметр ядра pcie_acs_override. Це може розділити групи так, що все виглядає ідеально.

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

Використовуйте ACS override лише якщо ризик для вас прийнятний: одноосібний хост, довірені гостьові ОС, заборона спільного хостингу і розуміння радіусу ураження. Інакше: змініть платформу, змініть слот або змініть план.

Жарт #1: ACS override — це як повісити табличку «Не входити» на двері без замка. Вона покращує атмосферу, але не безпеку.

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

• VT-d і AMD-Vi не створювалися для геймерів. Intel VT-d і AMD IOMMU (AMD-Vi) виникли з потреби безпечно віртуалізувати I/O у серверах і мультиорендних середовищах.
• DMA був первісним «повір мені, брате». Класичні PCI-пристрої могли DMA-записувати в пам’ять хоста майже без обмежень; IOMMU існує здебільшого, щоб зупинити один пристрій від хаотичного запису по всій пам’яті.
• ACS — це функція PCIe fabric, а не Linux-фічa. Linux може групувати на основі того, що репортує ієрархія PCIe щодо ізоляції.
• Перенаправлення переривань — частина історії безпеки. Навіть при DMA-ізоляції поломки в маршрутизації/перенаправленні переривань можуть спричинити нестабільність і проблеми під навантаженням.
• GPU стали «дивними» пристроями для passthrough через поведінку ресетів. Багато GPU не проектували для чистого функціонального ресету (FLR) з гостьової ОС; дехто вимагає ресету шини, дехто взагалі не скидається чисто.
• NVMe зазвичай простіше за GPU… поки ні. Контролери NVMe часто поводяться добре з FLR і управлінням namespace, але проблеми живлення і ASPM все ще можуть вдарити.
• SR-IOV зробив нормою ідею безпечного шарингу пристроїв. Вендори мережі й сховищ просували SR-IOV; віртуалізація GPU (vGPU) пішла іншим, більш вендорозалежним шляхом.
• Споживчі плати оптимізувалися під вартість, а не під ізоляцію. Багато десктопних чипсетів підключають кілька функцій за спільними мостами або свічами, які не відкривають ACS так, як це роблять серверні платформи.

Одна перефразована ідея, яку варто повісити на стіну: Hope is not a strategy — перефразовано багатьма операторами за роки; SRE-варіант: «заміри, а потім зміни».

Проєктування для чистого passthrough: обирайте битви, які можна виграти

1) Починайте з топології, а не з прапорців ядра

Перед тим як чіпати GRUB, дізнайтеся, що ви реально купили: які слоти — це CPU root-порти, які — лінії чипсету, які підключені до downstream-свічів, і які ділять міст з «усім іншим». Маркетингові діаграми — це упущення істини. Потрібно бачити PCIe-дерево.

2) Віддавайте перевагу лініям, приєднаним до CPU, для passthrough-пристроїв

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

3) Не передавайте в ВМ пристрій, з якого завантажується хост

Так, це можливо. Так, можна налаштувати. І так, це генератор простоїв при оновленнях прошивки, зміні initramfs або змінах в нумерації пристроїв. Тримайте завантаження хоста на чомусь нудному: маленький SATA SSD, дзеркальна пара або виділений M.2, який ви ніколи не віддаєте гостям.

4) GPU: плануйте ресети й володіння дисплеєм

Помилки passthrough GPU часто не є «проблемами IOMMU». Це проблеми ресету, ROM або власності драйвера.

• Reset: Якщо GPU не можна чисто ресетнути між зупинками/стартами ВМ, ви отримаєте прокляття «працює лише один раз після завантаження».
• ROM: Деяким налаштуванням потрібен ROM-файл GPU; інші ламаються, якщо ви змушуєте ROM.
• Володіння хостом: Якщо хост завантажує драйвер і захоплює framebuffer GPU на ранньому етапі, пізніше від’єднати його може бути складно.

5) NVMe: вирішуйте між passthrough і віртуалізованим сховищем залежно від домену відмов

NVMe passthrough чудовий для затратно-чутливих робочих навантажень, ігор у ВМ або однорендних аплайенсів. Але це змінює того, хто відповідає за відновлення після помилок.

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

6) Єдина розумна позиція з безпеки: вважайте passthrough-гісти довіреними

VFIO + IOMMU це сильна ізоляція, коли платформа її правильно підтримує, але passthrough розширює контроль гостя над реальним залізом. Якщо гість недовірений — перегляньте рішення. Якщо платформа потребує ACS override, не прикидайтеся, що ви будуєте загартовану мультиорендну систему.

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

Ви діагностуєте це найшвидше, якщо поводитиметесь як із будь-якою іншою операційною проблемою: спостерігайте, змінюйте одну річ, знову спостерігайте. Нижче — конкретні завдання, які можна виконати на Linux KVM хості (включно з середовищами на кшталт Proxmox) з нотатками про інтерпретацію виводу та рішеннями.

Завдання 1: Перевірте, чи ввімкнено IOMMU (завантаження ядра і dmesg)

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head -n 30
[    0.000000] ACPI: DMAR 0x0000000079B2B000 0000A8 (v01 INTEL  SKL      00000001 INTL 00000001)
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.000000] DMAR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.000000] DMAR: Enabled IRQ remapping in x2apic mode

Значення: Ви хочете бачити «IOMMU enabled» (Intel: DMAR) або «AMD-Vi: Enabled». Бонусні бали — «IRQ remapping enabled».

Рішення: Якщо ви не бачите IOMMU enabled, виправте налаштування прошивки (VT-d/AMD-Vi) і параметри ядра перед усім іншим.

Завдання 2: Підтвердіть командний рядок ядра (ловіть неправильні прапорці)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12 root=ZFS=rpool/ROOT/default ro quiet intel_iommu=on iommu=pt

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

Рішення: Тримайте iommu=pt для продуктивності, якщо ви не налагоджуєте щось екзотичне; зазвичай він підходить.

Завдання 3: Перелічіть IOMMU групи і знайдіть «монстра-групу»

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group $(basename "$g")"; for d in "$g"/devices/*; do echo -n "  "; lspci -nns "$(basename "$d")"; done; done | sed -n '1,80p'
IOMMU Group 0
  00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1237]
IOMMU Group 1
  00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:460d]
IOMMU Group 12
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
  01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22bc] (rev a1)
IOMMU Group 13
  02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Значення: Це правда. Ваш GPU зазвичай — дві функції (графіка + аудіо) і має бути в одній групі. Контролер NVMe ідеально має стояти сам або з нешкідливими сусідами, яких вам не потрібно.

Рішення: Якщо цільовий пристрій ділить групу з критичними для хоста пристроями (SATA-контролер, потрібний NIC, USB-контролер для вводу хоста), зупиніться і перерахуйте: інший слот, інша материнська плата або прийняття ризику ACS override.

Завдання 4: Подивіться дерево PCIe (знайдіть міст, що зливає групи)

cr0x@server:~$ lspci -tv
-+-[0000:00]-+-00.0  Intel Corporation Device 1237
 |           +-01.0-[01]----00.0  NVIDIA Corporation Device 2684
 |           |            \-00.1  NVIDIA Corporation Device 22bc
 |           +-03.0-[02]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller a808
 |           \-14.0  Intel Corporation Device 7ae0

Значення: Ви шукаєте, де підключено ваш пристрій: CPU root-порти проти мостів чипсету. Дерево допомагає корелювати «погане групування» з конкретним upstream-мостом.

Рішення: Якщо GPU/NVMe знаходиться за спільним downstream-свічем/мостом, спробуйте інший фізичний слот, який мапиться на інший root-порт.

Завдання 5: Ідентифікуйте ID пристроїв GPU/NVMe для зв’язування з vfio-pci

cr0x@server:~$ lspci -nn | egrep -i 'vga|audio|nvme'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22bc] (rev a1)
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Значення: Пари в дужках — vendor:device ID. Ви прив’язуєте ці ID до vfio-pci, щоб уникнути завантаження драйверів хоста на них.

Рішення: Захопіть усі функції, які плануєте передати (GPU + audio; іноді GPU має USB-C контролер теж).

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device 4101
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Значення: Якщо хост використовує nvidia або nouveau, passthrough буде складнішим. Для чистого VFIO ви хочете бачити Kernel driver in use: vfio-pci.

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

Завдання 7: Зв’яжіть пристрої з vfio-pci (modprobe конфіг) і перебудуйте initramfs

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:2684,10de:22bc,144d:a808 disable_vga=1
EOF
cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.12

Значення: Це примушує vfio-pci захопити ці device ID під час завантаження, до того як інші драйвери встигнуть.

Рішення: Перезавантажтеся після цієї зміни. Якщо не можете перезавантажитись, не робіть «live rebinding», якщо не хочете дебажити headless хост з підлоги.

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device 4101
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Значення: Модулі можуть існувати, але «driver in use» має бути vfio-pci.

Рішення: Якщо він досі зв’язаний з GPU-драйвером, ваша initramfs не включила vfio-налаштування достатньо рано або стек GPU дистрибутива змушує його. Виправте це перед запуском QEMU.

Завдання 9: Перевірте VFIO і IOMMU fault’и в логах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'vfio|iommu|dmar|fault' | tail -n 30
[Tue Feb  4 10:10:02 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Tue Feb  4 10:10:02 2026] vfio-pci 0000:02:00.0: enabling device (0000 -> 0002)
[Tue Feb  4 10:12:17 2026] DMAR: [DMA Read] Request device [02:00.0] fault addr 0x7f1c9000 [fault reason 0x02] Present bit in context entry is clear

Значення: VFIO «enabling device» — нормально. DMAR/IOMMU fault’и — ні. «Present bit in context entry is clear» часто вказує на проблему з мапуванням або некоректну поведінку пристрою.

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

Завдання 10: Перевірте перенаправлення переривань (стабільність і безпека)

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|irq remapping|x2apic' | head
[    0.000000] DMAR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.000000] DMAR: Enabled IRQ remapping in x2apic mode

Значення: Ви хочете бачити ввімкнене IRQ remapping, особливо якщо вам важлива надійність і ізоляція.

Рішення: Якщо воно вимкнене, перевірте налаштування BIOS (іноді прив’язано до «Above 4G decoding», «SR-IOV» або «Intel VT-d») і параметри ядра. На деяких платформах ввімкнення x2APIC допомагає.

Завдання 11: Перевірте використання ACS override (знайте, коли ви собі брешете)

cr0x@server:~$ cat /proc/cmdline | tr ' ' '\n' | egrep 'pcie_acs_override|acs'
pcie_acs_override=downstream,multifunction

Значення: Це «роздільник груп». Він може зробити групи виглядом чистими без того, щоб апарат насправді це примусово ізолював.

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

Завдання 12: Перевірте швидкість/ширину PCIe лінку (перформанс-як вузьке місце)

cr0x@server:~$ sudo lspci -s 02:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Значення: Ваш NVMe здатний на PCIe Gen4 x4, але працює на Gen3 x2. Це не віртуалізаційна проблема. Це проблема слоту, BIOS, райзера або цілісності сигналу.

Рішення: Виправте тренінг лінку перед будь-яким бенчмаркінгом. Поміняйте слот, приберіть райзер, оновіть BIOS або, якщо можливо, примусово вкажіть генерацію PCIe у прошивці.

Завдання 13: Перевірте членство пристрою в IOMMU group (хірургічний погляд)

cr0x@server:~$ dev=0000:02:00.0; readlink -f /sys/bus/pci/devices/$dev/iommu_group
/sys/kernel/iommu_groups/13

Значення: Це точно каже, до якої групи належить пристрій — зручно для скриптів і відстежування змін.

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

Завдання 14: Прикріпіть через QEMU/Libvirt і підтвердіть, що гість бачить реальний пристрій

cr0x@server:~$ sudo virsh domblklist win11-gpu
 Target   Source
------------------------------------------------
 vda      /var/lib/libvirt/images/win11.qcow2

cr0x@server:~$ sudo virsh dumpxml win11-gpu | egrep -n 'hostdev|address|vfio' | head -n 40
132:    
133:      
134:        

135:      

Значення: Визначення ВМ містить призначення PCI hostdev. Це і є ваш passthrough.

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

Завдання 15: Виміряйте латентність і I/O в гості проти хоста (пошук оверхеду віртуалізації)

cr0x@server:~$ sudo fio --name=randread --filename=/dev/nvme0n1 --ioengine=io_uring --direct=1 --bs=4k --iodepth=32 --numjobs=1 --runtime=15 --time_based --rw=randread
randread: (groupid=0, jobs=1): err= 0: pid=24111: Tue Feb  4 10:21:12 2026
  read: IOPS=182k, BW=712MiB/s (747MB/s)(10.4GiB/15001msec)
    slat (nsec): min=820, max=12514, avg=1790.12, stdev=402.21
    clat (usec): min=49, max=412, avg=173.40, stdev=21.11

Значення: Це базова продуктивність на хості. Порівняйте схожі прогони всередині гостя на переданому NVMe. Великі різниці вказують на проблему з модерацією переривань, управлінням живлення або плануванням CPU — не лише на VFIO.

Рішення: Якщо латентність гостя значно гірша за хоста, перевірте топологію CPU, C-states і чи використовує ВМ MSI/MSI-X правильно.

Завдання 16: Перевірте, чи NVMe підтримує ресет коректно (уникнення «працює один раз»)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | egrep -i 'frmw|oacs|oncs|vwc|lpa' | head
oacs    : 0x17
oncs    : 0x5f
vwc     : 0x1
lpa     : 0x3

Значення: Можливості відрізняються; ви в першу чергу перевіряєте, що контролер не якесь дешево-бюджетне диво, яке дивно поводиться при ресетах/подіях живлення.

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

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

Це рутина «я маю 20 хвилин і начальник поруч». Мета — визначити, чи ваш вузький аспект — ізоляція, володіння, ресет чи проста пропускна здатність PCIe.

По-перше: топологія та ізоляція (не налагоджуйте примар)

1. Перевірте IOMMU групи і підтвердіть, що цільовий пристрій не приклеєний до критичних хост-пристроїв.
2. Перевірте дерево PCIe щоб побачити, від якого мосту/root-порту залежить пристрій.
3. Перевірте ACS override і вирішіть, чи влаштовує вас рівень ризику.

По-друге: володіння драйверами і зв’язування (нудне, але ламає все)

1. Підтвердіть, що vfio-pci використовується для кожної функції, яку передаєте.
2. Проскануйте dmesg на предмет помилок VFIO, DMAR fault та статусу перенаправлення переривань.
3. Перевірте конфіг ВМ, щоб пересвідчитись, що вона містить hostdev-пристрої і ви випадково не бенчмаркуєте віртуальний диск.

По-третє: продуктивність і стабільність (де «працює» стає «придатним до використання»)

1. Перевірте ширину/швидкість лінку на предмет пониження (класика: Gen4 пристрій працює на Gen3 x1).
2. Зробіть короткий fio тест на хості і в гості для порівняння латентності та IOPS.
3. Шукайте симптоми «працює один раз» після зупинки/старту ВМ, пов’язані з ресетами.

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

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

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

Середня компанія побудувала внутрішній «пул GPU» для CI-навантажень: збірка, тести й інколи CUDA. Вони купили декілька споживчих робочих станцій, вставили по парі GPU в кожну і запустили KVM з VFIO. На перших випробуваннях виглядало чисто. Один GPU на ВМ. Всі задоволені.

Потім прокотився апдейт ядра і групування IOMMU в деяких хостів змінилося тонко. Та сама модель материнської плати, але різні версії прошивки. На тих хостах GPU опинився в групі разом із USB-контролером, який також обслуговував зовнішній KVM-dongle для віддаленого доступу. Ніхто не помітив, бо ВМ все ще стартувала.

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

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

Виправлення було банальне: стандартизувати версії BIOS, прив’язати SKU апаратури і додати pre-flight перевірку, яка валідує членство в групах перед провізіонуванням GPU-ВМ. Також перестали підключати єдиний канал віддалого менеджменту до контролера, який може опинитись переданим ВМ.

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

Інша організація хотіла низької латентності зберігання всередині Windows-ВМ для інструмента обробки даних з вимогливими ліцензіями. Вони пробили NVMe прямо в ВМ. Продуктивність була фантастичною. Бенчмарки були вражаючі.

Потім реальність нагрянула: ВМ час від часу видала BSOD під сильними записами, і іноді контролер NVMe зависав. Хост бачив пристрій, який існує, але не завершував команди. Теплий ребут не завжди реанімував його. Іноді потрібен був повний power-cycle шасі.

Вони оптимізували не ту метрику. Оптимізація була для стейт-фул продуктивності, а не для поведінки при відновленні. Проблема не в самому passthrough; проблема була в тому, що область відповідальності перемістилась у гостьову ОС і її стек драйверів, а апарат не скидався на їхній платформі надійно.

Вирішенням стало відмовитися від ілюзії, що потрібен голий NVMe для цього навантаження. Вони перемістили ВМ на віртуальний диск, підкріплений сховищем хоста з належним write-caching і регулярними snapshot’ами. Один виділений NVMe хост для невеликого набору навантажень з перевіреними контролерами і тестованим шляхом ресету залишили.

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

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

Команда фінансових сервісів запускала кілька високовартісних робочих ВМ для інженерії та візуалізації. Вони мали суворий change management — непопулярний, поки не стане єдиною перешкодою між вами і хаосом. У їхньому runbook вимагалось зберігати PCIe-топологію і списки IOMMU груп як артефакти щоразу після оновлення прошивки.

Одного кварталу оновлення постачальника «покращило сумісність PCIe». У стенді нічого не провалилось. Але їхній diff артефактів показав, що група GPU тепер включає новий сусідній пристрій: PCIe bridge function, раніше прихований. Це не мало значення для bare metal, але мало значення для VFIO, бо міст притягнув інші пристрої.

Оскільки вони помітили це до релізу, вони зупинились. Протестували альтернативні слоти, знайшли той, що зберігає GPU ізольованим, і оновили стандарт складання: «GPU має бути в слоті X; NVMe passthrough — на CPU M.2 слоті Y».

Коли реліз потрапив у продакшн, усе пройшло нудно. Без сюрпризів. Команда майже розчарувалась.

Жарт #2: Change management — як чистка зубів: ніхто не хоче це робити, але наслідки пропуску дорогі й дивні.

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

1) ВМ не стартує: «Device is in use» / «cannot reset»

Симптоми: QEMU помилки про скидання пристрою, або «device is in use». ВМ стартує тільки один раз після завантаження.

Корінь: Драйвер хоста захопив пристрій першим, або пристрій не підтримує FLR чисто, або відсутній належний шлях bus reset.

Виправлення: Прив’яжіть до vfio-pci в initramfs; уникайте host framebuffer; розгляньте іншу модель GPU; переконайтесь, що пристрій один у своїй групі; для GPU з багами ресету перевірте вендор-залежні обхідні шляхи або змініть апарат.

2) GPU passthrough працює, але продуктивність жахлива

Симптоми: Низький FPS, стуттер, високе завантаження CPU або гість поводиться так, ніби використовує базовий display adapter.

Корінь: GPU фактично не передано (використовується virtio-gpu), PCIe лінк понижений, в гості не встановлено драйвер або є проблеми з плануванням/прив’язкою CPU.

Виправлення: Переконайтесь, що гість бачить модель GPU; перевірте lspci -vv на предмет стану лінку; встановіть коректні драйвери гостя; прив’яжіть vCPU до фізичних ядер і уникайте overcommit для чутливих до латентності робочих навантажень.

3) NVMe passthrough дає гарні бенчмарки, а потім корумпується або зникає

Симптоми: Помилки I/O у гості, ресети NVMe, пристрій зникає до перезавантаження/power cycle.

Корінь: Квірки прошивки контролера в умовах віртуалізації, проблеми управління живленням/ASPM, неправильна поведінка при ресеті або нестабільність платформи.

Виправлення: Вимкніть ASPM для цього лінку за потреби; оновіть BIOS/прошивку NVMe; спробуйте інший контролер; якщо потрібна надійність — перейдіть на віртуальні диски, якими керує хост.

4) Після ввімкнення IOMMU мережа хоста ламається або стає нестабільною

Симптоми: Втрати пакетів, ресети NIC, дивні сплески латентності.

Корінь: Деякі драйвери/платформи поводяться інакше з DMA remapping; проблеми з перенаправленням переривань; баги BIOS.

Виправлення: Переконайтесь, що IRQ remapping увімкнено; оновіть BIOS; протестуйте інше ядро; розгляньте iommu=pt; якщо це баг платформи — не боріться з ним, замініть плату.

5) «IOMMU group велика, тож я просто передам її всю»

Симптоми: Хост втрачає сховище/NIC/USB; раптові простої при старті ВМ.

Корінь: Передача групи, що містить критичні для хоста пристрої.

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

6) ACS override «виправляє» групи, але пізніше вводить моторошні явища

Симптоми: Рідкі DMA/IOMMU fault’и, дивна нестабільність, паніка під час аудиту безпеки.

Корінь: Примусове розділення груп без гарантій апаратної ACS-ізоляції.

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

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

Крок за кроком: отримати чистий GPU passthrough

1. Налаштування прошивки: Увімкніть VT-d/AMD-Vi. Увімкніть «Above 4G decoding», якщо у вас сучасні GPU і кілька пристроїв.
2. Прапорці завантаження: Додайте intel_iommu=on або amd_iommu=on; розгляньте iommu=pt для продуктивності хоста.
3. Змапуйте групи: Перелічіть IOMMU групи і підтвердіть, що GPU (і його audio) ізольовані від критичних для хоста пристроїв.
4. Обирайте правильний слот: Надавайте перевагу CPU root-портам. Якщо слот йде через міст/свіч чипсету, частіше утворюються брудні групи.
5. Зв’яжіть рано: Налаштуйте vfio-pci IDs і заблокуйте конфліктні GPU-драйвери; перебудуйте initramfs.
6. Підтвердіть володіння: Після перезавантаження впевніться, що Kernel driver in use: vfio-pci.
7. Конфіг ВМ: Передайте всі потрібні функції GPU (графіка + аудіо; іноді USB-C контролер).
8. Тест стабільності: Запустіть/зупиніть ВМ кілька разів. Якщо працює лише один раз — маєте проблему ресету, яку треба вирішити перед фінішем.

Крок за кроком: отримати чистий NVMe passthrough

1. Визначте домен відмов: Якщо гість відповідає за відновлення, passthrough підходить. Якщо хост має відновлювати і робити snapshot’и — віддайте перевагу віртуальним дискам.
2. Ізолюйте контролер: Переконайтесь, що IOMMU група контролера NVMe не включає завантажувальне сховище хоста або потрібний NIC.
3. Перевірте статус лінку: Підтвердіть очікувану генерацію і ширину PCIe. Виправте пониження спочатку.
4. Зв’яжіть з vfio-pci: Як і з GPU, робіть це рано й послідовно.
5. Верифікація гостя: Переконайтесь, що гість бачить реальний NVMe контролер і драйвери коректні.
6. Тест навантаження: Виконайте короткі жорсткі I/O тести. Слідкуйте за dmesg хоста на предмет ресетів або DMAR fault’ів.
7. Управління живленням: Якщо виникають проблеми стабільності, тестуйте зміни ASPM і оновлення прошивки.

Операційний чекліст: не дайте регресу статися

• Фіксуйте PCIe топологію (lspci -tv) і IOMMU групи як артефакти для кожного хоста.
• Стандартизуйте версії BIOS/UEFI у кластері.
• Після оновлень прошивки перевіряйте членство в групах і зв’язування пристроїв перед запуском робочих навантажень.
• Тримайте завантаження хоста окремо від passthrough-пристроїв.
• Майте шлях відкату для змін ядра та initramfs.

FAQ

1) Чому я не можу передати лише один пристрій з IOMMU групи?

Тому що межа групи — це межа безпеки ядра для DMA-ізоляції. Якщо пристрої не можна ізолювати, передача одного ризикує тим, що інші пристрої зроблять DMA в не ту пам’ять.

2) Чи однакові IOMMU групи з PCIe лініями або слотами?

Ні. Групи формуються топологією PCIe і можливостями ACS. Один фізичний слот може бути за мостом, що зливає домени ізоляції.

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

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

4) Мій GPU ділить групу зі своєю аудіофункцією. Це погано?

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

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

Зазвичай це проблема ресету: GPU не підтримує FLR чисто або платформа не може його коректно ресетнути після зупинки ВМ. Також впливають прив’язка, ROM-особливості та поведінка вендорських драйверів.

6) NVMe passthrough проти virtio-blk на ZFS/LVM: що «краще»?

Для сирого латентності і прямого контролю NVMe passthrough часто виграє. Для операційної безпеки — snapshot’и, реплікація, відновлення на рівні хоста — віртуальні диски на хост-менеджованому сховищі зазвичай виграють.

7) Чи послаблює iommu=pt ізоляцію?

Зазвичай він застосовує passthrough-мапи для пристроїв, що належать хосту, щоб зменшити накладні витрати, тоді як пристрої VFIO все ще використовують строгі мапи. Це широко використовується; провалідуйте у вашому середовищі.

8) Який найшвидший спосіб зрозуміти, що проблеми продуктивності пов’язані з PCIe?

Перевірте LnkSta через lspci -vv. Якщо лінк понижено в швидкості чи ширині — виправте це перед налаштуванням ВМ.

9) Передавати весь NVMe контролер чи використовувати namespaces?

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

10) Чи можливо зробити чистий passthrough на споживчому залізі?

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

Висновок: практичні наступні кроки

Якщо ви хочете чистий passthrough GPU/NVMe, перестаньте ставитися до IOMMU груп як до перешкоди, яку можна переспорити. Вони — серум істини апаратного забезпечення.

Зробіть наступне:

1. Зробіть інвентар поточного групування і PCIe-дерева. Збережіть його. Трактуйте як конфіг, бо це конфіг.
2. Перемістіть пристрій у слот/root-порт, приєднаний до CPU, якщо групування некрасиве.
3. Зв’яжіть з vfio-pci рано, підтвердіть володіння після перезавантаження і відмовтесь від налагодження драйверів гостя, поки хост не буде чистим.
4. Зробіть бенчмарк швидкості/ширини лінку та латентності до й після, щоб знати, чи щось покращилось.
5. Якщо ви покладаєтесь на ACS override для «безпеки», зупиніться і перегляньте проєкт: або прийміть довірених гостей, або купіть правильну платформу.

Коли passthrough чистий — це радість. Коли ні — це кар’єра у тлумаченні повідомлень про помилки. Оберіть радість. Виправте топологію.