ACS override у Proxmox: ярлик, який може коштувати стабільності (зробіть ось що натомість)

February 21, 2026 • February 21, 2026 • Читання: 6 хв • Views: 0

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

Ви зробили це. Увімкнули PCIe passthrough на Proxmox, подивилися на IOMMU групи, які нагадували ящик з мотлохом,
і хтось на форумі вимовив чарівні слова: «ACS override». Один перезавантаження — і ваша GPU нарешті з’являється в VM.
Ви почуваєтеся хитро. Ідете спати.

А потім хост починає поводитися ніби привид: періодичні зависання VM, таймаути NVMe, спонтанні перезавантаження під навантаженням,
або та повільна течія «виправлених» помилок PCIe, що переростає в відмову у п’ятницю ввечері. ACS override не «полагодив» вашу платформу.
Він наказав ядру робити вигляд, що апаратна ізоляція краща, ніж є насправді. Іноді це спрацьовує. Іноді це пастка.

Що насправді робить ACS override (і чого не робить)

У світі PCIe ви не стільки «пропускаєте пристрій», скільки переконуєте хост припинити до нього чіплятися й передаєте VM
пряму власність через VFIO. Безпека й стабільність такої схеми залежать від меж ізоляції, які надає платформа:
IOMMU групування, можливості ACS, перенаправлення переривань, поведінка скидання та проста топологія PCIe.

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

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

Ось неприємна частина: з ACS override ви можете створити конфігурацію, яка для VFIO та менеджера VM виглядає ізольованою,
але не є такою на шині. Якщо два пристрої все ще можуть робити peer-to-peer DMA або ділитися upstream-шляхом без належної ізоляції,
ви побудували систему, яка «працює», поки не перестає. Ви можете отримати крахи, ризик корупції даних або дивні патерни продуктивності,
що не відтворюються стабільно.

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

Що змінює ACS override

Воно змінює формування груп. Пристрої можуть з’являтися в різних IOMMU групах навіть якщо платформа не забезпечує це розділення.
Воно змінює те, що Proxmox дозволяє вам робити. Ви можете прив’язати одиночний пристрій до VFIO, не забираючи разом всю групу.

Чого ACS override не змінює

Воно не додає апаратної ізоляції. Якщо PCIe-шлях позбавлений ACS, він і надалі його не матиме.
Воно не виправляє проблеми зі скиданням. «Reset-баги» GPU та проблеми з FLR лишаються.
Воно не гарантує безпеку DMA. У найгіршому разі переданий пристрій все ще може впливати на пам’ять хоста або інші пристрої.
Воно не вирішує проблем із перенаправленням переривань. Якщо ваша платформа не може коректно ремапити переривання, ви все ще отримаєте важкодіагностовані зависання.

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

Чому люди тягнуться до ACS override на Proxmox

Proxmox робить VFIO доступним. Це добре. Але виробники апаратного забезпечення не проектують споживчі платформи для чистих IOMMU груп;
вони проектують їх під цільову ціну та маркетингові довідкові пункти. Отже з’являються класичні неприємності:

Ваша GPU згрупована з USB-контролером чипсета й SATA-контролером.
Ваші NVMe слоти ділять root port з чимось, що потрібно хосту.
HBA знаходиться за мостом із іншими пристроями, які ви не можете передати.
У вашої платформи ввімкнено IOMMU, але перенаправлення переривань часткове або ненадійне.

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

Жарт №1: ACS override — як використовувати скотч як несучий елемент. Тримає, поки вантажність не нагадає про себе.

Витрати на стабільність: реальні режими відмов

Поговорімо про конкретні шляхи, як це йде шкереберть. Не теоретичні «дослідники безпеки могли б…», а реальний операційний біль.

1) Сюрпризи з DMA та peer-to-peer

Якщо два пристрої фактично не ізольовані, переданий пристрій може дістатися до пам’яті чи інших пристроїв способами, яких ви не очікували.
Навіть якщо вас не турбує зловмисна поведінка, «неочікуваний peer-to-peer» може проявлятися як:

Нестабільність хоста, коли драйвер у VM вмикає розширені можливості.
Таймаути пристрою під навантаженням, що виглядають як проблеми з кабелем (хоча це PCIe).
Недітермінована поведінка, коли кілька VM конкурують за спільні upstream-шляхи.

2) Перенаправлення переривань і «випадкові» зависання

Деякі платформи підтримують трансляцію IOMMU, але мають слабке або баговане перенаправлення переривань. Коли ви передаєте пристрої,
які генерують багато переривань (GPU, NVMe, HBA, NIC), ви можете отримати зависання VM або повні зависання хоста.
Люди звинувачують драйвери. Іноді драйвер — не винуватець.
Злодієм є платформа і її «переривальна» проводка.

3) СПАМ AER, який ви ігноруєте, поки він не вдарить

Advanced Error Reporting (AER) логуватиме виправлені й невиправлені помилки PCIe. Виправлені помилки можуть виглядати нешкідливими — поки їхня частота не зросте й продуктивність не впаде,
або поки невиправлена помилка не виллється в скидання пристрою під час IO. ACS override сам по собі не викликає помилок AER, але воно може змусити вас
поставити високонавантажені пристрої за сумнівною топологією, через що маргінальні лінії покажуть свій справжній характер.

4) Відмова «працювало місяцями»

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

5) Ризик корупції зберігання при неправильному passthrough

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

6) Кліфф продуктивності: спільні root complex і прихований контеншн

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

Стрибки затримки NVMe, коли GPU під навантаженням.
Втрати пакетів або джиттер на passthrough NIC під час піків зберігання.
CPU soft lockup через шторми переривань, коли система не може ефективно ремапити їх.

Цікаві факти та історія (коротко, корисно, трохи нудно)

Семантика IOMMU груп у Linux навмисно консервативна. Ядро групує пристрої разом, якщо не може довести ізоляцію. Це свідома параноїдна поведінка, а не лінощі.
ACS виник через потреби специфікації PCIe у керуванні мультифункційністю та комутованими фабриками. Сервери з PCIe комутаторами й великою кількістю endpoint’ів потребували механізмів примусу; настільні системи часто ігнорують це.
VT-d (Intel) та AMD-Vi (AMD IOMMU) дозріли під час буму віртуалізації. Ранні реалізації існували, але надійний passthrough став масовим лише тоді, коли віртуалізація стала дефолтом, а не нішевою опцією.
Proxmox не винайшов VFIO; він його опрацював. VFIO — це фреймворк ядра Linux; Proxmox — зручний інтерфейс, що робить людей сміливими натискати «Add PCI Device.»
Перенаправлення переривань було моментом «о, так». Саме трансляція адрес і переклад доступів була недостатня; безпечне призначення пристроїв потребує такого ж уважного поводження з перериваннями.
Споживчі чипсети часто підключають пристрої до тих самих upstream портів. Ось чому ваш USB-контролер і SATA-контролер можуть опинитися в одній IOMMU групі.
Поведінка скидання GPU довго була болючою точкою. Підтримка FLR варіює, драйвери від вендорів різні, і результат — відомий патерн «працює до перезавантаження VM».
AER-логування старше, ніж багато хто думає. PCIe давно вміє повідомляти, що лінія хворіє; ми просто стали дуже добрими в ігноруванні цих повідомлень.
ACS override існує тому, що користувачі просили про нього. Це прагматичний інструмент для розробки та домашніх лабораторій, а не печатка архітектурного схвалення.

Швидка діагностика (плейбук для пошуку вузьких місць)

Коли passthrough нестабільний, можна витратити дні на драйверні легенди. Не треба. Почніть з топології та доказів.
Ось порядок, який заощадив мені найбільше часу.

Перше: підтвердіть, що у вас справді є IOMMU + перенаправлення переривань

Перевірте командний рядок ядра на наявність налаштувань IOMMU для AMD/Intel.
Перевірте dmesg на наявність «DMAR» (Intel) або «AMD-Vi» та повідомлень про ввімкнене перенаправлення переривань.
Якщо перенаправлення переривань відсутнє/вимкнене, очікуйте дивні зависання під навантаженням.

Друге: огляньте IOMMU групи й реальну топологію PCIe

Перелічіть групи з /sys/kernel/iommu_groups.
Порівняйте з lspci -t та lspci -vv, щоб побачити, які пристрої ділять мости/root-порти.
Якщо увімкнено ACS override, ставтеся до розбиття груп як до «логічного», а не обов’язково «фізичного».

Третє: шукайте AER, скидання та помилки VFIO

Шукайте в логах AER, DPC, «BAR», «vfio», «DMAR fault», «IOMMU fault».
Корелюйте з часами навантаження. Якщо помилки з’являються під час старту/стопу VM, підозрюйте поведінку скидання/FLR.

Четверте: ізолюйте змінні, змінюючи по одній

Тимчасово вимкніть ACS override і перевірте, чи зникає проблема (навіть якщо це порушить розкладку).
Перемістіть пристрій в інший слот/root-порт, якщо можливо.
Оновлюйте прошивку/BIOS лише після того, як захопили базові логи.

П’яте: вирішіть, чи це архітектурна проблема

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

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

Це перевірки, які я справді виконую на Proxmox (Debian-based), коли хтось каже «ACS override виправило» й я хочу зрозуміти, на що ми підписалися.
Кожне завдання включає: команду, приклад виводу, що це означає та яке рішення прийняти.

Task 1: Confirm IOMMU is enabled in the running kernel

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet amd_iommu=on iommu=pt

Що це означає: Ви завантажені з ввімкненим AMD IOMMU; iommu=pt використовує passthrough-режим для хостових пристроїв (часто добре для продуктивності).

Рішення: Якщо ви не бачите intel_iommu=on або amd_iommu=on, виправте це перед тим, як торкатися ACS override або VFIO.

Task 2: Verify IOMMU and interrupt remapping in dmesg (Intel)

cr0x@server:~$ dmesg -T | egrep -i "DMAR|IOMMU|remapping" | head -n 20
[Tue Feb  4 10:12:11 2026] DMAR: IOMMU enabled
[Tue Feb  4 10:12:11 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Що це означає: Intel VT-d активний і перенаправлення IRQ увімкнено. Це хороший сценарій.

Рішення: Якщо ви бачите «IRQ remapping disabled» або нічого про IR, вважайте ризик для passthrough вищим.

Task 3: Verify IOMMU and interrupt remapping in dmesg (AMD)

cr0x@server:~$ dmesg -T | egrep -i "AMD-Vi|IOMMU|remap|IVRS" | head -n 30
[Tue Feb  4 10:12:10 2026] AMD-Vi: IOMMU performance counters supported
[Tue Feb  4 10:12:10 2026] AMD-Vi: Interrupt remapping enabled

Що це означає: AMD IOMMU працює і перенаправлення переривань увімкнене.

Рішення: Немає перенаправлення переривань? Не «латайте» це ACS override. Очікуйте проблем з пристроями, що генерують багато переривань.

Task 4: Check whether ACS override is enabled

cr0x@server:~$ grep -R "pcie_acs_override" -n /etc/default/grub /etc/kernel/cmdline 2>/dev/null
/etc/default/grub:6:GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

Що це означає: ACS override явно ввімкнено.

Рішення: Ставте під сумнів кожну «чисту» IOMMU групу, поки не доведете їх топологією та бітами можливостей ACS.

Task 5: Enumerate IOMMU groups the straightforward way

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}:"; lspci -nns $(ls "$g"/devices | sed 's/^/0000:/'); echo; done | head -n 40
Group 12:
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
03:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Group 13:
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Що це означає: GPU і її аудіофункція згруповані разом (очікувано). NVMe у іншій групі (добре, можливо).

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

Task 6: View PCIe topology as a tree (who shares which bridge)

cr0x@server:~$ lspci -t
-+-[0000:00]-+-00.0
 |           +-01.0-[01]----00.0
 |           +-03.0-[02-05]--+-00.0
 |           |               +-00.1
 |           |               \-01.0
 |           \-08.1-[06]----00.0

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

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

Task 7: Check whether the relevant bridges advertise ACS capability

cr0x@server:~$ lspci -vv -s 00:03.0 | egrep -i "ACSCap|ACSCtl|PCIe Cap|Root Port" -n
45:00:03.0 PCI bridge: Intel Corporation Device 7a44 (rev 11)
86:	Capabilities: [148 v1] Access Control Services
87:		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
88:		ACSCtl: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+

Що це означає: Цей міст дійсно має ACS. Це добре; розділення груп тут ймовірніше «реальне».

Рішення: Якщо міст не має ACS, а ви спираєтесь на ACS override, щоб розділити пристрої за ним, ви ставитеся на ризик.

Task 8: Confirm VFIO bindings for the passthrough device

cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5162]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Що це означає: GPU прив’язана до vfio-pci, а не до хостового графічного драйвера.

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

Task 9: Look for IOMMU faults and DMAR/AMD-Vi errors during VM use

cr0x@server:~$ journalctl -k --since "2 hours ago" | egrep -i "DMAR|AMD-Vi|IOMMU fault|vfio|AER" | tail -n 30
Feb 04 09:41:22 server kernel: vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258
Feb 04 09:58:03 server kernel: pcieport 0000:00:03.0: AER: Corrected error received: 0000:04:00.0
Feb 04 09:58:03 server kernel: nvme 0000:04:00.0: AER: [0] RxErr (First)

Що це означає: Виправлені помилки PCIe на NVMe-лінії. Не миттєво фатально, але повідомляє, що фізичне посилання не в порядку.

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

Task 10: Check whether your NVMe is dropping queues or timing out

cr0x@server:~$ journalctl -k --since "24 hours ago" | egrep -i "nvme.*timeout|I/O.*timeout|resetting controller|frozen" | tail -n 20
Feb 03 22:14:19 server kernel: nvme nvme0: I/O 124 QID 7 timeout, aborting
Feb 03 22:14:19 server kernel: nvme nvme0: Abort status: 0x371
Feb 03 22:14:20 server kernel: nvme nvme0: resetting controller

Що це означає: Контролер NVMe таймаутиться і робить скидання. Якщо це збігається з навантаженням GPU/VM, підозрюйте спільний PCIe шлях або проблеми сигналізації.

Рішення: Не звинувачуйте ZFS спочатку. Виправте транспорт. Розгляньте переміщення NVMe у слот, підключений до CPU, або вимкнення агресивного енергозбереження.

Task 11: Confirm virtualization features and IOMMU visibility

cr0x@server:~$ pveversion -v | head -n 5
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.2 (running version: 8.2.2/1a3f7d3e)
pve-kernel-6.8: 6.8.12-4

Що це означає: Ви можете корелювати поведінку з версіями ядра. Регресії VFIO та особливості PCIe можуть бути специфічні для ядра.

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

Task 12: Inspect QEMU VM config for passthrough options that affect reset and ROM

cr0x@server:~$ cat /etc/pve/qemu-server/101.conf
agent: 1
bios: ovmf
boot: order=scsi0;net0
cpu: host
hostpci0: 0000:03:00,pcie=1,x-vga=1
machine: q35
memory: 16384
name: gpu-vm
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
ostype: win11
scsi0: local-lvm:vm-101-disk-0,size=200G

Що це означає: OVMF + q35 + cpu: host — типовий набір для passthrough GPU.

Рішення: Якщо ви бачите legacy BIOS, i440fx або дивні поєднання, уніфікуйте спочатку. Налагодження екзотичних конфігурацій VM — це зайве навантаження.

Task 13: Check whether the device supports FLR (Function Level Reset)

cr0x@server:~$ lspci -vv -s 03:00.0 | egrep -i "FLR|Reset" -n
210:	Capabilities: [1b0 v1] Transaction Processing Hints
233:	Capabilities: [300 v1] Secondary PCI Express
262:	Kernel driver in use: vfio-pci

Що це означає: Цей фрагмент явно не показує FLR; багато пристроїв не афішують його так, щоби користувач помітив. Проте поведінка скидання має практичне значення.

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

Task 14: Validate that the host isn’t accidentally using the passed-through GPU for console

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x  2 root root       80 Feb  4 10:12 by-path
crw-rw----  1 root video 226,   0 Feb  4 10:12 card0
crw-rw----  1 root render 226, 128 Feb  4 10:12 renderD128

Що це означає: Існують DRM-пристрої. Якщо передана GPU прив’язана до VFIO, вона зазвичай не має з’являтися як активний DRM-пристрій у стеку хоста.

Рішення: Якщо хост використовує GPU (framebuffer/DRM), виправте це: додайте драйвери в чорний список, встановіть базову GPU у BIOS (primary GPU) і забезпечте раннє біндування VFIO.

Task 15: Confirm that your intended HBA is in a clean group before passthrough

cr0x@server:~$ lspci -nn | egrep -i "SAS|HBA|LSI|Broadcom|MegaRAID"
81:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)

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

Що це означає: HBA у групі 26. Тепер перелічіть, що ще в цій групі, перед тим як передавати її.

Рішення: Якщо в групі є щось крім HBA (або його очікуваних функцій), не спирайтеся на ACS override, щоб «зробити це нормально». Змініть слоти або плату.

Task 16: Check CPU/chipset lane attachment hints (quick-and-dirty)

cr0x@server:~$ lspci -vv -s 04:00.0 | egrep -i "LnkCap|LnkSta" 
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 16GT/s, Width x4

Що це означає: Лінк на очікуваній швидкості/ширині. Якщо ви бачите x1 або нижчу швидкість ніж очікувана, ви знайшли підказку про проблеми з продуктивністю чи стабільністю.

Рішення: Виправте фізичне встановлення, налаштування BIOS PCIe, райзери або вибір слота перед тим, як звинувачувати Proxmox чи VFIO.

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

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

Середня компанія зібрала кластер Proxmox для агентів збірки та кількох внутрішніх сервісів. У них був один сервер з GPU для CI-робіт:
браузерні тести, кодування відео та кілька CUDA-завдань. GPU була встановлена в робочій станції на платі, що виглядала «майже серверною».

Інженер, який налаштовував систему, побачив страшні IOMMU групи й увімкнув ACS override. VM з GPU завантажилася. Бенчмарки виглядали добре. Всі перейшли далі.
Їхнє припущення було простим: «Якщо в своїй IOMMU групі — значить ізольовано». Ядро сказало так. Тож це має бути правда.

Через кілька тижнів вони почали бачити спорадичні збої в зовсім інших VM на тому самому хості. Не щодня. Не при кожному навантаженні.
Збої були бісових: VM зависала на 30–90 секунд, відновлювалася, але з пошкодженим станом додатків. Іноді хост логував виправлені PCIe помилки.
Іноді — нічого.

Зрештою виявилося, що зависання корелювали з високою DMA-активністю GPU і великим NVMe IO одночасно.
Топологія PCIe показала, що обидва пристрої за спільним upstream-портом без належного ACS. ACS override розділив групи логічно,
але шина все ще поводилася як район з тонкими стінами.

Виправлення було нудним і дорогим: вони перемістили GPU в інший слот, що перенесло її під інший root-порт, і замінили райзер, який був маргінальним на Gen4.
Вони вимкнули ACS override після підтвердження, що групи чисті без нього. Стабільність повернулася одразу. Ніхто не сумував за «хитрощами».

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

Інша організація намагалася вичавити максимум продуктивності із хоста, орієнтованого на зберігання. Вони передавали HBA у VM TrueNAS
і одночасно передавали високошвидкісний NIC у VM-роутер. Плата не давала їм чистих груп. ACS override виглядав як спосіб уникнути покупки нової платформи.

Вони також увімкнули iommu=pt та декілька «перформансних» BIOS-налаштувань: тонке ASPM, відключили агресивне енергозбереження і примусили деякі PCIe швидкості.
Мета — низька латентність і висока пропускна здатність. Результат спочатку вражав бенчмарками.

Потім сталося неприємне: під тривалим трафіком NIC VM іноді втрачав лінк на секунду. Недовго, щоб викликати явні тривоги,
але достатньо, щоб спричинити TCP retransmits і таймаути додатків вище по ланцюгу. Тим часом storage VM логував інколи скидання контролера.
Хост сам по собі не падав, тому всі думали, що проблема в гостевих системах.

Насправді це був контеншн і відновлення помилок на спільному PCIe шляху, який ACS override дозволив ігнорувати.
«Оптимізація» збільшила навантаження й штовхнула лінк у режим відновлення помилок. Кількість виправлених AER помилок зросла. Латентність стала різкою.

Вони відкотили примусову BIOS-настройку, потім перемістили один пристрій у слот, підключений до CPU. Продуктивність на папері трохи впала,
але мережа перестала гикати. Графіки послуг стали нудними знову. Нудне — це й є мета.

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

Команда фінансових сервісів запускала Proxmox для внутрішніх навантажень із суворим процесом управління змінами (так, вони є).
Вони хотіли passthrough GPU для невеликого аналітичного навантаження. Обладнання було сервельним з чіткими root-портами та валідацією VT-d.

Провідний SRE наполягав на чеклісті: зафіксувати топологію PCIe, записати IOMMU групи до змін, перевірити перенаправлення переривань і провести burn-in тест.
ACS override тільки за умови доказу ACS на upstream-шляху. Це було непопулярно. Люди хотіли VM сьогодні.

Під час burn-in вони спіймали постійну течію виправлених AER помилок на upstream-порті GPU при Gen4. Система «працювала», але логи були незадоволеними.
Вони переставили GPU в інший слот і помилки зникли. Ймовірно, проблема була в посадці або цілісності сигналу на тому слоті, але філософської відповіді не потребували.
Потрібна була чиста робота.

Через місяці оновлення прошивки змінило поведінку еквалізації PCIe, і інша команда почала бачити AER-шуми на схожих хостах.
Ця команда вже мала базові логи й знімки топології, тому вони негайно порівняли «до» і «після».
Вони уникли днів гадань і звузили проблему до конкретної ревізії BIOS.

Їхня практика не була гламурною. Вона також була причиною того, що ніхто не отримав стороження о 2 ранку.

Зробіть натомість: безпечніші способи реалізувати passthrough

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

Опція A: Використайте правильний слот (топологія — це фіча)

Багато плат мають один або два слоти, пряму підключені до CPU root complex, а інші підключені через чипсет.
Слоти, підключені до CPU, зазвичай мають чистішу ізоляцію і менше сюрпризів «всі з усіма діляться».

Перемістіть пристрій. Так, фізично. Дивовижно багато «проблем VFIO» насправді — «ви обрали слот, який дизайнер плати використав для зручності».

Опція B: Обирайте обладнання з реальним ACS і адекватним IOMMU групуванням

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

Чітке відокремлення ліній CPU від ліній чипсета
Наявність ACS на мостах/root-портах
Валідація VT-d/AMD-Vi з перенаправленням переривань

Опція C: Передайте всю групу (коли це розумно)

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

Це добре працює, коли група — «GPU + аудіо GPU» або «USB-контролер, яким можна пожертвувати». Погано працює, коли в групу входить зберігання або мережа,
які потрібні хосту. Це сигнал, що платформа — проблема, а не Proxmox.

Опція D: Перестаньте передавати невідповідний клас пристроїв

Якщо ви хочете продуктивності для зберігання, не завжди потрібен HBA passthrough. Іноді virtio-scsi на хості з ZFS простіше й безпечніше.
Якщо потрібне GPU-прискорення для конкретної програми, інколи контейнер з правильним доступом до пристрою достатній (і уникає ризиків на шинному рівні).

Опція E: Якщо мусите використовувати ACS override — окресліть межі та тестуйте по-справжньому

Іноді ви застрягли. Бюджет, апаратні обмеження, час. Якщо вирішили все ж використовувати ACS override, ставтеся до цього як до контрольованого випалювання:

Увімкніть його лише щоб перевірити можливість, потім намагайтеся прибрати, змінивши слоти або обладнання.
Запустіть burn-in тест під реалістичним IO та навантаженням переривань.
Моніторьте AER, IOMMU faults, скидання і затримки постійно.
Майте шлях відкату і задокументуйте, чому цей ризик прийняли.

Жарт №2: Якщо ваш план доступності — «увімкнув ACS override і молився», вітаю — ви реалізували інфраструктуру на основі віри.

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

Ось повторювані випадки. Не моральні прогріхи. Просто патерни.

1) Симптом: VM працює добре до перезавантаження; потім passthrough GPU не працює

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

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

2) Симптом: Хост зависає під IO або навантаженням GPU

Корінь: Відсутнє/вимкнене перенаправлення переривань або баги платформного IOMMU при високій частоті переривань.

Виправлення: Переконайтеся, що dmesg показує ввімкнене перенаправлення переривань. Оновіть BIOS/прошивку. Якщо IR не можна ввімкнути стабільно, не робіть passthrough пристроїв із великою кількістю переривань на цій платформі.

3) Симптом: Скачки затримки зберігання, коли GPU VM завантажена

Корінь: Спільний root порт/ uplink комутатора, прихований контеншн, часто зроблений невидимим розбиттям груп ACS override.

Виправлення: Перемістіть пристрої на різні CPU root-порти; уникайте використання чипсетних ліній для обох важких пристроїв. Перевірте за допомогою lspci -t і параметрів link width/speed.

4) Симптом: Кількість виправлених AER помилок повільно зростає в логах

Корінь: Маргінальна сигналізація PCIe (посадка пристрою, райзер, живлення, примусова швидкість Gen або планування плати).

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

5) Симптом: «Пристрій у власній IOMMU групі», але відбуваються дивні взаємодії між пристроями

Корінь: ACS override створив логічні групи без реального примусу ACS.

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

6) Симптом: VFIO прив’язаний, але пристрій все ще виглядає зайнятим драйверами хоста

Корінь: Проблеми з порядком бінду драйверів; відсутня конфігурація initramfs для раннього завантаження VFIO; хост-консоль використовує GPU.

Виправлення: Забезпечте раннє завантаження модулів VFIO, внесіть конкурируючі модулі в чорний список, встановіть primary GPU у BIOS на iGPU/іншу карту і перевірте lspci -nnk знову.

7) Симптом: Передача HBA викликає спорадичні помилки ZFS у storage VM

Корінь: HBA ділить групу/топологію з іншими пристроями; події помилок PCIe/скидання; або проблеми з управлінням живленням.

Виправлення: Розмістіть HBA на чистому root-порті; уникайте ACS override; використовуйте enterprise HBA з стабільною прошивкою; слідкуйте за AER і скиданнями контролера.

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

Контрольний список A: Перед тим як увімкнути ACS override (прохід «не жалкуй пізніше»)

Підтвердіть, що IOMMU увімкнено в /proc/cmdline.
Підтвердіть перенаправлення переривань у dmesg (DMAR-IR або AMD-Vi interrupt remapping).
Збережіть вивід lspci -t для топології.
Збережіть перелік IOMMU груп з /sys/kernel/iommu_groups.
Перевірте відповідні мости на наявність ACS через lspci -vv.
Вирішіть, чи можна передати всю групу замість її розбиття.
Вирішіть, чи допоможе переміщення слотів усунути потребу в override.

Контрольний список B: Якщо ви вже ввімкнули ACS override (стабілізація або відкат)

Документуйте точні параметри ядра та версію Proxmox.
Запустіть 2–4 годинний burn-in, що відповідає реальному навантаженню (GPU + зберігання + мережа).
Моніторьте journalctl -k на предмет AER, IOMMU faults, VFIO reset-повідомлень.
Якщо бачите зростання виправлених AER помилок, спочатку розглядайте апарат/топологію.
Спробуйте перемістити пристрій в інший слот і повторіть burn-in.
Спробуйте вимкнути ACS override і перевірте, чи групування стає прийнятним.
Якщо не можете прибрати ACS override, встановіть очікування: вищий операційний ризик, посилений моніторинг і протестований шлях відкату.

Контрольний список C: Приймальний тест PCI passthrough для продакшену

Cold boot хоста, старт VM, навантаження 60 хвилин.
Зупиніть VM, запустіть знову (тест шляху скидання), знову запустіть навантаження.
Міґруйте несуміжні VM з хоста і назад, якщо ваша інфраструктура це робить (стрес тест планування).
Зніміть AER лічильники і порівняйте початок і кінець.
Переконайтеся: немає NVMe скидань, немає мережевих флапів, немає soft lockups хоста.

FAQ

1) ACS override «небезпечний» чи просто «непідтримуваний»?

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

2) Якщо моя VM працює, чому мені хвилюватися про «реальну» ізоляцію?

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

3) Чи завжди ACS override спричиняє нестабільність?

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

4) Чи можу я використати ACS override тільки для одного пристрою?

Параметр ядра впливає на поведінку формування груп загалом (в залежності від режиму). Ви не можете акуратно обмежити його тільки одним endpoint’ом так, як це можна зробити з прив’язкою VFIO.
Ставтеся до цього як до зміни поведінки на всьому хості.

5) Яка найкраща альтернатива, коли моя GPU ділить групу з SATA або USB?

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

6) Я запускаю ZFS у VM з passthrough HBA. Чи коли-небудь ACS override прийнятний?

Це множник ризику. Якщо HBA не справді ізольований, ви створюєте шлях, де помилки на шині можуть вплинути на надійність зберігання.
Для зберігання я суворіший: уникаю ACS override, якщо не перевірено ACS на upstream-шляху і не виконано burn-in під реальним IO.

7) За чим стежити в логах, щоб рано побачити проблему?

Повідомлення AER, «resetting controller» для NVMe, IOMMU faults, DMAR/AMD-Vi помилки і повідомлення VFIO про скидання або відображення BAR.
Якщо виправлені помилки мають тренд зростання — не ігноруйте їх.

8) Чи робить `iommu=pt` passthrough менш безпечним?

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

9) Чи може оновлення ядра змінити IOMMU групування?

Так. Патчі ядра щодо quirks PCI та обробки ACS можуть змінити. Ось чому варто зберігати «відомі добрі» групування та топологію і перевіряти їх після великих оновлень.

10) Коли ACS override є розумним тимчасовим інструментом?

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

Наступні кроки, які ви можете зробити цього тижня

Якщо ви зараз використовуєте ACS override на Proxmox-хості, що має значення — не «увімкнути і забути». Зробіть наступне:

Зберіть докази: збережіть /proc/cmdline, вивід lspci -t і повний перелік IOMMU груп.
Перевірте ремапінг: підтвердіть перенаправлення переривань у dmesg. Якщо його немає — припиніть вважати систему стабільною.
Аудит мостів: перевірте ACS можливості на upstream-шляху пристроїв, які ви передаєте.
Burn-in тест: запустіть реальне навантаження і слідкуйте за AER/IOMMU/NVMe reset-повідомленнями. Якщо логи шумлять — спочатку виправляйте фізику/топологію.
Спробуйте прибрати override: перемістіть слоти, передайте цілі групи або змініть обладнання, поки групи не стануть чисті без того, щоб ядро робило вигляд.

Мета не чистота. Мета — передбачувані домени відмов. Якщо ACS override — єдине, що відокремлює вас від працездатної системи,
це сигнал до редизайну — не привід святкувати.

Схожі статті

Оновлення ядра зламало passthrough? Як швидко діагностувати IOMMU Proxmox vs ESXi для ZFS: вибір шляху контролера диска (HBA passthrough чи віртуальні диски)