Чому ваш GPU passthrough дає чорний екран після перезавантаження (часто винна IOMMU)

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

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

1) Підтвердіть, що пристрій залишився тим самим

• Перевірте, що PCI-адреса і ID пристрою не змінилися (рідко, але трапляється при оновленнях BIOS або змінах слоту).
• Підтвердіть, що і GPU, і його аудіофункція присутні.

2) Підтвердіть, що VFIO дійсно прив’язав GPU під час завантаження

• Якщо драйвер ядра хоста (nouveau, nvidia, amdgpu) прив’язався раніше, VFIO «програє» і ваша VM отримає примару.
• Проблеми з прив’язкою часто виникають після оновлень ядра та змін initramfs.

3) Підтвердіть, що IOMMU-групи лишаються ізольованими

• Якщо ваш GPU ділить IOMMU-групу з чимось, що потрібно хосту, ви або відмовитесь запускати VM, або запустите її і отримаєте чорний екран.
• Членство в групі може змінюватися після перемикання BIOS, оновлення прошивки або змін параметрів ядра.

4) Перевірте проблеми зі скиданням/FLR

• Якщо воно працює один раз, а потім ламається після перезавантаження або після зупинки/запуску VM, швидше за все це особливість скидання.
• Це проявляється як «VM завантажується, вивід відсутній» або «драйвер гостя завантажився, але потім пристрій зникає».

5) Підтвердіть, що шлях виводу відео не бреше

• Неправильний вхід монітора, проблеми DP handshake або KVM-перемикач можуть виглядати як збої VFIO.
• Перевірте через інший вихід (HDMI замість DP) або використайте відому робочу dummy-plug.

Жарт №1: GPU passthrough — єдине місце, де «вчора працювало» вважається загрозою моделі безпеки.

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

«Чорний екран» — це симптом, а не діагноз. У VFIO GPU passthrough це зазвичай означає одне з наступного:

• Гість ніколи не отримував GPU: драйвер хоста прив’язав пристрій, або QEMU не зміг призначити його через конфлікти IOMMU-груп.
• Гість отримав GPU, але він ніколи не ініціалізував вивід: відсутній option ROM, неправильний режим прошивки (UEFI vs legacy) або некоректний стан після скидання.
• Гість ініціалізувався, але ви дивитесь на неправильний вихід: плутанина між мультимоніторами або виходами; GPU рендерить десь іще.
• GPU у «завислому» стані: відома проблема для деяких споживчих GPU без належного Function Level Reset (FLR).

Корисна ментальна модель: passthrough — це ланцюг опіки (custody chain). PCIe-пристрій «належить» комусь у кожний момент:
прошивка, драйвер хоста, VFIO, QEMU, драйвер гостя. Чорні екрани часто виникають, коли власник змінюється,
але стан не скидається коректно — або коли неправильний власник хапає пристрій першим.

Чому IOMMU зазвичай винна

IOMMU (Intel VT-d / AMD-Vi) — це «контролер доступу до пам’яті» на вході в клуб. Він обмежує DMA, щоб пристрої не могли читати та писати
випадкову пам’ять. Для passthrough це обов’язково: ваш гостьовий GPU має виконувати DMA лише в пам’ять, призначену гостю,
а не в кеш хоста або секрети гіпервізора.

Частина, котра підводить після перезавантаження: топологія IOMMU — це не просто «вкл/викл». Її формують:
налаштування BIOS, топологія PCIe, параметри ядра, можливості ACS і іноді креативність виробника плати.
Це означає, що ви можете мати робочу конфігурацію, яка непомітно перестає бути ізольованою після перезавантаження,
оновлення прошивки або навіть іншого порядку завантаження пристроїв.

IOMMU-групи: справжня одиниця ізоляції

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

Після перезавантаження членство в групі може змінитися, бо прошивка по-іншому перерахувала дерево PCIe,
або бо перемкнулися налаштування ACS у BIOS. Іноді «невинне» оновлення BIOS вирішує, що кореневий порт чіпсета
має поводитися інакше, і тепер ваш GPU приклеєний до половини машини.

ACS override: спокусливо, іноді необхідно, завжди компроміс

Параметр ядра ACS override може розділити групи, які апаратно не ізолюються правильно.
Це може зробити passthrough можливим на споживчих платформах, але також створює помилкове відчуття безпеки:
ви кажете ядру вважати ізоляцію наявною, хоча електрично її може не бути.

У виробничих середовищах я ставлюся до ACS override як до закручування скотчу на гальма. Можливо, ви доберетеся додому.
Але ви не повинні будувати кластер навколо цього.

Перемапування переривань і чому «IOMMU вкл.» — недостатньо

Деяким платформам потрібно увімкнути перерозподіл переривань (interrupt remapping) для безпечного passthrough. Без нього ви можете бачити дивні збої:
пристрої, що виглядають призначеними, але поводяться мертво, гості зависають під час ініціалізації драйвера, або шаблон «працює до перезавантаження».
Саме тут «я увімкнув VT-d» перетворюється на казку. Потрібно перевірити, що ядро справді активувало ці можливості.

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

1. VFIO замінив старі підходи призначення пристроїв у KVM, перемістивши доступ до пристроїв у безпечніший фреймворк, керований IOMMU, замість імпровізованих мап.
2. IOMMU існує насамперед для ізоляції DMA; віртуалізація зробила його відомим, але проблема безпеки (пристрої як DMA-агресори) існувала задовго до сплеску homelab.
3. PCIe ACS не «придуманий для геймерів»; це серверна функція для ізоляції та контролю маршрутизації, а споживчі чіпсети часто реалізують її частково або не реалізують взагалі.
4. Багато GPU мають кілька PCI-функцій (графіка + HDMI audio + іноді USB-C/VirtualLink). Часто потрібно передавати всі пов’язані функції разом для стабільності.
5. Function Level Reset (FLR) не є універсальним; деякі споживчі GPU історично не мали надійної поведінки скидання, спричиняючи помилки «працює один раз».
6. UEFI GOP vs legacy VGA ROM має значення: сучасні GPU віддають перевагу ініціалізації через UEFI; legacy CSM шляхи можуть поводитися по-різному після перезавантажень і оновлень прошивки.
7. Resizable BAR змінив очікування щодо мапування ресурсів PCIe; увімкнення/вимкнення може впливати на те, як пристрої відображають пам’ять, і іноді на те, як прошивка перераховує пристрої.
8. Ранній VGA-арбітраж досі існує: концепт «primary GPU» впливає на те, яке firmware-пристрій ініціалізує першим, що впливає на прив’язку драйвера хоста й passthrough.

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

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

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

cr0x@server:~$ dmesg | egrep -i 'iommu|vt-d|amd-vi' | head -n 20
[    0.612345] DMAR: IOMMU enabled
[    0.612678] DMAR: Host address width 39
[    0.613012] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.950123] DMAR: Interrupt remapping enabled

Значення: Ядро знайшло DMAR-таблиці (Intel) і увімкнуло IOMMU плюс перемапування переривань.

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

Завдання 2: Перевірити поточний cmdline ядра на наявність параметрів IOMMU і passthrough

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.13 root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt vfio-pci.ids=10de:1b80,10de:10f0

Значення: Ви просите Intel IOMMU, режим passthrough для непрохідних пристроїв (iommu=pt) і попередню прив’язку VFIO до конкретних PCI ID.

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

Завдання 3: Ідентифікувати GPU та його функції (графіка + аудіо)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|audio' 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)

Значення: Ваш GPU знаходиться на 01:00.0, а HDMI-аудіо — на 01:00.1. Зазвичай їх потрібно передавати разом.

Рішення: Якщо аудіофункція відсутня після перезавантаження, підозрюйте зміни перерахунку PCIe, проблемний riser або некоректну опцію BIOS типу «PCIe power saving».

Завдання 4: Подивитись, який драйвер зараз володіє GPU (перевірка ланцюга опіки)

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] GP104 [GeForce GTX 1080] [1462:3363]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Значення: Добре: Kernel driver in use: vfio-pci. Хост не використовує пристрій.

Рішення: Якщо ви бачите nouveau, nvidia або amdgpu як «in use», ваш passthrough буде нестабільним або мертвим. Виправте прив’язку драйвера перед тим, як дивитися IOMMU-групи.

Завдання 5: Перевірити членство в IOMMU-групі (істина ізоляції)

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do g=$(basename $(dirname $d)); printf "Group %s: " "$g"; lspci -nns ${d##*/}; done | egrep '01:00'
Group 16: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
Group 16: 01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)

Значення: Ідеально: функції GPU перебувають самі разом у одній групі.

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

Завдання 6: Виявити використання ACS override (і визнати ризик)

cr0x@server:~$ dmesg | egrep -i 'ACS|override' | head
[    1.245678] PCI: Using ACS override for IOMMU isolation

Значення: Ядро підробляє/розділяє ізоляцію.

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

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

cr0x@server:~$ lsmod | egrep '^vfio|^irqbypass'
vfio_pci               65536  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   57344  2 vfio_pci_core,vfio_iommu_type1
irqbypass              16384  1 kvm

Значення: Стек VFIO присутній.

Рішення: Якщо модулів нема, перевірте initramfs і чорні списки модулів. Оновлення ядра можуть нудно скинути вашу конфігурацію.

Завдання 8: Перевірити вміст initramfs опосередковано (чи відбувається прив’язка vfio достатньо рано?)

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

Значення: Ви налаштовуєте ранню прив’язку VFIO через опції modprobe і забезпечуєте завантаження модулів.

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

Завдання 9: Підтвердити, що GPU не є пристроєм консолі/фреймбуфером завантаження

cr0x@server:~$ dmesg | egrep -i 'fb0|framebuffer|efifb|vesafb' | head -n 20
[    0.401234] efifb: probing for efifb
[    0.401567] efifb: framebuffer at 0xc0000000, using 3072k, total 3072k
[    0.401890] fb0: EFI VGA frame buffer device

Значення: Хост використовує EFI framebuffer, який може (або не може) бути на вашому passthrough GPU.

Рішення: Якщо passthrough GPU є первинним пристроєм відображення, ви будете боротися з прошивкою та прив’язкою консолі. Віддайте перевагу iGPU або дешевому другому GPU для хоста.

Завдання 10: Шукати повідомлення «GPU fell off the bus» / AER / помилки лінку після перезавантаження

cr0x@server:~$ journalctl -b -k | egrep -i 'AER|pcie|fallen off|vfio|DMAR|amdgpu|nvidia' | tail -n 30
Feb 04 09:11:21 server kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

Значення: Є скориговані помилки PCIe. Не завжди фатально, але якщо вони корелюють з чорними екранами, можливо проблеми з цілісністю сигналу або енергоуправлінням.

Рішення: Спробуйте інший слот, вимкніть ASPM в BIOS, оновіть BIOS або приберіть risery. Не «оптимізуйте», поки не стане стабільно.

Завдання 11: Перевірити помилки призначення QEMU/libvirt (випадок «він ніколи не прикріпився»)

cr0x@server:~$ journalctl -u libvirtd -b --no-pager | tail -n 30
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123456Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: vfio 0000:01:00.0: group 16 is not viable
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123499Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: Please ensure all devices within the iommu_group are bound to their vfio bus driver.

Значення: Класика: IOMMU-група містить щось, що не прив’язане до VFIO, тому QEMU відмовляється або завершується.

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

Завдання 12: Підтвердити режим прошивки гостя і обробку ROM GPU

cr0x@server:~$ virsh dumpxml win11-gpu | egrep -n 'loader|nvram|hostdev|rom' | head -n 40
52:  /usr/share/OVMF/OVMF_CODE.fd
53:  /var/lib/libvirt/qemu/nvram/win11-gpu_VARS.fd
120: 
121:   
122:     

123:   
124:   
125: 

Значення: VM використовує OVMF (UEFI). ROM BAR увімкнено (це не те саме, що постачання файлу ROM, але важливо).

Рішення: Якщо ви використовуєте legacy BIOS (SeaBIOS) з сучасним GPU і бачите чорні екрани після перезавантаження, перемкніться на OVMF, якщо немає специфічної причини не робити цього.

Завдання 13: Перевірити класичний «NVIDIA Code 43» і відрізнити його від проблем IOMMU

cr0x@server:~$ virsh qemu-agent-command win11-gpu '{"execute":"guest-get-osinfo"}'
{"return":{"id":"mswindows","name":"Microsoft Windows","pretty-name":"Microsoft Windows 11","version":"10.0"}}

Значення: Guest agent відповідає; гостьова ОС жива, навіть якщо ви бачите чорний екран.

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

Завдання 14: Перевірити, чи GPU не залишається «у використанні» процесом хоста

cr0x@server:~$ fuser -v /dev/vfio/16 2>/dev/null
                     USER        PID ACCESS COMMAND
/dev/vfio/16:        libvirt-qemu  2451 F.... qemu-system-x86

Значення: VFIO-група утримується процесом QEMU. Це очікувано, коли VM працює.

Рішення: Якщо щось інше тримає її (або вона зайнята після зупинки VM), у вас проблема зі звільненням/скиданням. Виправте shutdown hooks і розгляньте vendor-reset або політику повного відключення живлення.

Завдання 15: Примусово перевірити прапори можливостей IOMMU для Intel-платформ

cr0x@server:~$ dmesg | egrep -i 'DMAR:.*(Queued|remapping|fault|cap)' | head -n 30
[    0.612678] DMAR: IOMMU enabled
[    0.950123] DMAR: Interrupt remapping enabled
[    0.950456] DMAR: Queued invalidation enabled

Значення: У вас є шматки, які роблять passthrough менш привидним.

Рішення: Якщо перемапування переривань відсутнє, шукайте опції BIOS типу «Interrupt Remapping» або «Posted Interrupt». Деякі плати ховають це під «Security».

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

cr0x@server:~$ lspci -vv -s 01:00.0 | egrep -i 'Capabilities:.*Express|FLR|Reset' -n | head -n 30
25:Capabilities: [60] Express (v2) Endpoint, MSI 00

Значення: Цей фрагмент сам по собі не підтверджує FLR, але lspci -vv — це місце, де шукати можливості, пов’язані зі скиданням.

Рішення: Якщо ви постійно бачите «працює один раз» і карта не має хорошого скидання, плануйте компенсатори: vendor-reset для деяких AMD-карт, повний power-cycle хоста після зупинки VM або вибір іншого GPU.

Три корпоративні історії з реальних випадків

Інцидент №1: Хибне припущення («Ребут — це чистий старт»)

Середня компанія керувала невеликим VDI-пулом для дизайн-команди. Нічого екзотичного: KVM, VFIO, кілька GPU на хості, Windows-гості.
У стейджингу все працювало тижнями. Потім прийшов Patch Tuesday, і всі перезавантажили хости на вихідних.
В понеділок вранці: третина VM з’явилася з чорними екранами.

Припущення, закріплене в їхньому ранубуку, було простим: перезавантаження хоста скидає апарат, тож GPU завжди повернеться в чистому стані.
Це припущення виявилося хибним у двох сенсах. По-перше, GPU був первинним пристроєм відображення в BIOS на деяких хостах,
тож прошивка та фреймбуфер хоста торкалися його перед тим, як VFIO міг його забрати. По-друге, налаштування BIOS
(«fast boot») змінило час ініціалізації PCIe і змінювало, які пристрої потрапляли в які IOMMU-групи.

Діагностика зайняла більше часу, ніж повинна була, бо команда ганялася за логами драйверів гостя.
Ці логи були реальними, але не причинними. GPU в проблемних випадках ніколи по-справжньому не належав гостю.
Доказ був у lspci -nnk: на зламаних хостах драйвер хоста володів GPU.

Виправлення було нудним і ефективним: стандартизувати налаштування BIOS, примусово встановити iGPU як первинний для хоста,
і забезпечити прив’язку VFIO в initramfs з правильними ID для GPU та аудіофункції. Після цього перезавантаження стали передбачуваними знову — а це єдина бажана поведінка в продакшні.

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

Інша організація хотіла максимальну продуктивність GPU для обчислювальних навантажень у гостях. Хтось (з добрими намірами)
увімкнув Resizable BAR, Above 4G decoding та кілька опцій управління живленням PCIe по всьому кластеру.
На папері це могло допомогти певним навантаженням. На практиці це ввело непослідовний час завантаження ресурсів PCIe.

Негайний симптом не був продуктивністю. Це були переривчасті чорні екрани після перезавантаження, зосереджені на одній моделі материнської плати.
Деякі хости піднімалися з GPU в IOMMU-групі, яка тепер включала PCIe-бридж і USB-контролер.
QEMU іноді відмовлявся запускатися, іноді VM стартувала, але GPU не ініціалізував вивід.
Команда втратила день, бо зміни були «налаштуваннями продуктивності», і ніхто не пов’язав їх з ізоляцією.

Постмортем був різким: якщо ваша платформа не валідована для тих перемикачів, ставте їх як експериментальні.
Вони спочатку відкотили налаштування управління живленням, потім валідовували Resizable BAR хост за хостом.
Стабільність повернулася. Продуктивність теж — бо продуктивність приходить після надійності, а не замість неї.

Жарт №2: Якщо ви тиснете всі BIOS-перемикачі з написом «turbo», ви не налаштовуєте — ви записуєтесь у лотерею перезавантажень.

Інцидент №3: Нудна практика, що врятувала день («Базові докази після кожної зміни»)

Більш дисциплінована команда вела невелику програму «golden host». Кожного разу, коли вони змінювали прошивку, ядро або пакети гіпервізора,
вони знімали пакет базових даних: /proc/cmdline, рядки dmesg про IOMMU, списки IOMMU-груп і
lspci -nnk для GPU. Вони зберігали це з тикетом зміни. Ніхто цього не святкував.
Це була паперова робота з виводом команд.

Потім рутинне оновлення ядра співпало з проблемою чорного екрану після перезавантаження на двох хостах.
Замість сперечань про те, «чи це драйвер GPU», вони зробили diff між базовими пакетами.
Курящим доказом стало те, що cmdline більше не містив очікуваних VFIO ID на уражених хостах.
Фрагмент конфігурації завантажувача був перезаписаний під час переходу пакета.

Виправлення було швидким, бо їм не треба було наново відкривати систему; потрібно було лише відновити її.
Вони виправили конфіг завантажувача, відновили initramfs і один раз перезавантажилися. VM повернулися.
Велика перемога не була технічною геніальністю — це було мати доказ того, як виглядає «працює».

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

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

1) Чорний екран лише після перезавантаження; холодний старт працює

Корінь: Квірк скидання GPU. Пристрій не повертається в чистий стан при «теплому» старті або stop/start VM.

Виправлення: Віддавайте перевагу GPU з правильною підтримкою FLR; спробуйте обхідні рішення скидання в модулі/ядрі (де застосовно), або вимагайте повного power-cycle хоста після зупинки VM. Уникайте станів «suspend» для хоста.

2) VM стартує, гість доступний (RDP/SSH), але фізичний монітор залишається чорним

Корінь: Невідповідність виходу (неправильний порт), невідповідність UEFI/ROM ініціалізації або драйвер гостя обирає інший шлях виводу.

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

3) QEMU/libvirt скаржиться «group is not viable» після перезавантаження

Корінь: IOMMU-група містить інші пристрої, не прив’язані до VFIO, або група змінилася після оновлення прошивки.

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

4) GPU після перезавантаження прив’язується до nouveau/nvidia/amdgpu на хості

Корінь: Прив’язка VFIO відбувається не рано; initramfs не містить конфігурації vfio; чорні списки не застосовані при завантаженні.

Виправлення: Вкажіть ID для vfio-pci в конфігурації modprobe; заблокуйте драйвери хоста при потребі; згенеруйте initramfs заново; перевірте lspci -nnk після перезавантаження.

5) Все працювало, доки ви не ввімкнули «fast boot» або не змінили CSM/UEFI

Корінь: Змінено шлях ініціалізації прошивки; змінилася первинна GPU; змінилася поведінка option ROM.

Виправлення: Вимкніть fast boot для хостів з passthrough; стандартизуйте режим UEFI; встановіть непрохідний GPU як первинний, якщо можливо.

6) Драйвер гостя завантажується, потім падає; пристрій зникає або видає помилки

Корінь: Невідповідність функцій перемапування переривань або IOMMU; іноді MSI/MSI-X квірки.

Виправлення: Перевірте перемапування переривань у dmesg; оновіть BIOS; переконайтесь, що VT-d/AMD-Vi повністю увімкнено; спробуйте новіше ядро.

7) Чорний екран збігається з AER-спамом PCIe після перезавантаження

Корінь: Цілісність сигналу (riser-кабелі), енергоменеджмент (ASPM), слабкий БП або проблеми тренування слота.

Виправлення: Приберіть risery; спробуйте інший слот; вимкніть ASPM; оновіть BIOS; перевірте подачу живлення.

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

Базовий чекліст (зробіть, коли все працює)

1. Збережіть /proc/cmdline і прикріпіть його до нотаток про зміни.
2. Збережіть рядки dmesg, що підтверджують IOMMU + перемапування переривань.
3. Збережіть членство IOMMU-груп для функцій GPU.
4. Збережіть lspci -nnk, яке показує vfio-pci як «in use» для GPU і аудіо.
5. Збережіть режим прошивки VM (OVMF vs SeaBIOS) і мапінг hostdev.

План відновлення, коли ви перезавантажилися і отримали чорний екран

1. Зупиніть VM (якщо вона працює), щоб уникнути повторних ініціалізацій пристрою, що ускладнюють логи.
2. Підтвердіть PCI-адреси GPU не змінилися (lspci -nn).
3. Перевірте володіння драйвером (lspci -nnk -s 01:00.0 і 01:00.1).
4. Перевірте IOMMU-групи і впевніться, що група життєздатна.
5. Перегляньте логи ядра на AER і VFIO-помилки (journalctl -b -k).
6. Підтвердіть режим прошивки (рекомендовано OVMF для сучасних гостів) і приберіть конфліктні віртуальні дисплеї.
7. Якщо це проблема скидання, спробуйте повний power-cycle хоста (не просто reboot). Якщо це вирішує — плануйте пом’якшення наслідків повільнішого скидання.

План жорсткого загартування (щоб перезавантаження стали нудними)

1. Стандартизуйте налаштування BIOS по всіх хостах: VT-d/AMD-Vi увімкнено, interrupt remapping увімкнено, fast boot вимкнено.
2. Віддавайте перевагу виділеному хостовому пристрою відображення (iGPU або дешевий другий GPU), щоби прошивка не ініціалізувала ваш passthrough GPU.
3. Прив’язуйте VFIO в initramfs, а не «пізно» під час завантаження. Пізня прив’язка — це гонка, яку ви зрештою програєте.
4. Уникайте ACS override у середовищах з високими вимогами до ізоляції; якщо змушені використовувати — документуйте і регулярно переглядайте.
5. Після кожного оновлення BIOS/ядра перевіряйте IOMMU-групи. Трактуйте це як міграцію схеми, бо саме так воно і є.

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

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

1) Чому все працює, поки я не перезавантажу хост?

Перезавантаження змінює ланцюг опіки. Прошивка може ініціалізувати GPU інакше, драйвер хоста може прив’язатися раніше,
і IOMMU-групи можуть бути перераховані інакше. Теплі перезавантаження також не завжди коректно скидають споживчі GPU.

2) Чи завжди потрібен IOMMU для GPU passthrough?

Для безпечного і коректного passthrough на сучасних системах: так. Без IOMMU ізоляція DMA не забезпечується,
і VFIO не може безпечно призначити пристрій гостю.

3) У чому різниця між intel_iommu=on і iommu=pt?

intel_iommu=on увімкнює Intel IOMMU. iommu=pt ставить непрохідні пристрої в passthrough-режим, щоб зменшити накладні витрати.
Ви все одно маєте ізоляцію для пристроїв, які прив’язані до VFIO; просто ви не змушуєте трансляцію для всього іншого.

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

Зазвичай так. Багато GPU — мультифункціональні пристрої і поводяться краще, коли всі пов’язані функції в одній IOMMU-групі передаються разом.
Пропуск аудіофункції може спричинити дивну ініціалізацію або проблеми зі скиданням.

5) Якщо в моїй IOMMU-групі є інші пристрої, чи можу я пасструвати лише GPU?

Практично: іноді, з ACS override або небезпечними конфігураціями. Коректно: група — це одиниця ізоляції.
Якщо в групі є пристрої, критичні для хоста, довгострокове рішення — зміна апаратури/слота/топології, а не «форсувати» ситуацію.

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

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

7) Чому VM працює, але я не бачу відео?

Тому що «VM працює» означає лише, що QEMU живий. Відео залежить від ініціалізації GPU, режиму прошивки і вибору виходу.
Перевірте, що гість бачить GPU, і спробуйте OVMF плюс інший фізичний шлях виводу.

8) Варто використовувати OVMF (UEFI) чи SeaBIOS?

Для сучасного Windows і сучасних GPU OVMF зазвичай найменше проблемний шлях. SeaBIOS може працювати, але підвищує ризик проблем з ROM/ініціалізацією.
Якщо ви відстежуєте чорні екрани після перезавантаження, перехід на OVMF часто дає позитивний ефект.

9) Що робити, якщо у хоста немає iGPU і лише один GPU?

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

10) Яка єдина найкорисніша команда при відлагодженні?

lspci -nnk для функцій GPU. Вона показує, хто зараз володіє пристроєм. Володіння — це історія.

Висновок: наступні кроки, які можна виконати сьогодні

Якщо ваш GPU passthrough дає чорний екран після перезавантаження, припиніть трактувати це як містичний настрій GPU.
Трактуйте це як системну проблему: перевірте, що IOMMU увімкнено і має всі потрібні можливості, що VFIO прив’язується рано,
що IOMMU-групи стабільні й ізольовані, і лише потім шукайте квірки скидання і дивності шляху виводу.

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

• Запустіть Завдання 1–5 і збережіть виводи. Це ваш базис та ціль для diff.
• Зробіть прив’язку VFIO детерміністичною при завантаженні (initramfs), а не «згодом».
• Перевіряйте IOMMU-групи після будь-яких змін BIOS або ядра. Припускайте, що вони змінилися, поки не доведете протилежне.
• Якщо ваша платформа потребує ACS override, вважайте це апаратною проблемою вибору — а не тріумфом налаштування ядра.
• Якщо ви підтвердите проблему скидання, сплануйте політику пом’якшення (power cycle, інший GPU або допоміжне скидання), замість того щоб перезавантажуватися і сподіватися.

Мета — не змусити це працювати одного разу. Мета — щоб воно пережило наступне перезавантаження без церемоній.