iommu=pt: Прихований режим продуктивності для віртуалізації Linux (коли його використовувати)

February 12, 2026 • February 12, 2026 • Читання: 5 хв • Views: 1

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

Ви купуєте швидкі процесори, швидкі мережеві адаптери, швидкі NVMe, а платформа віртуалізації працює, ніби тягне піаніно по сходах.
Підскакує затримка. Рівень пакетів коливається. IOPS для сховища в бенчмарку виглядають добре, а в продакшні — дивно.
Хтось каже «можливо, це IOMMU», і в кімнаті настає тиша, бо це твердження одночасно правдиве й дороге.

iommu=pt — один із тих перемикачів ядра Linux, який може відчуватися як безкоштовне підвищення продуктивності — поки це не так.
Він може зменшити накладні витрати на шляху DMA-мапінгу, особливо при інтенсивних навантаженнях віртуалізації вводу-виводу.
Водночас він може непомітно позбавити захистів, на які ви покладалися, або ускладнити налагодження.
Це польовий посібник: коли вмикати, коли ні і як довести, що ви виправляєте саме ту проблему.

Що насправді робить `iommu=pt` (не те, що інтернет думає)

IOMMU (Input-Output Memory Management Unit) — це MMU для пристроїв. Він транслює адреси, видимі пристрою (IOVA),
у фізичні адреси хоста та забезпечує ізоляцію, щоб пристрій не міг DMA-писати куди заманеться.
У віртуалізації це ключовий будівельний блок для безпечного passthrough PCI (VFIO), ізоляції SR-IOV і інколи
навіть для «просто virtio» залежно від вашого стека.

Linux підтримує кілька режимів роботи IOMMU. Деталі залежать від архітектури та драйвера (Intel VT-d, AMD-Vi,
arm-smmu тощо), але загальна картина така:

Translated mode: пристрої виконують DMA через таблиці сторінок IOMMU; ядро налаштовує відображення і може робити
ізоляцію по пристроях.
Pass-through mode: пристрої використовують «ідентичні» відображення (або еквівалент), тож трансляції DMA фактично 1:1 і накладні витрати на відображення знижуються.
Disabled: немає трансляції IOMMU; можливості ізоляції зникають, і деякі просунуті функції віртуалізації припиняють працювати.

iommu=pt просить Linux за замовчуванням використовувати passthrough-відображення для пристроїв, які не призначені гостям
(а іноді й ще до прив’язки, залежно від драйвера та життєвого циклу пристрою). Це не означає «немає IOMMU».
Це означає «тримати IOMMU увімкненим, але уникати накладних витрат перекладу там, де ізоляція не потрібна».

Суть: коли ви потім прив’язуєте пристрій до VFIO і передаєте його VM, ядро все одно використовує translated mode для цього
пристрою (бо потрібна ізоляція між гостем і хостом). Виграш найчастіше стосується всього іншого: пристроїв хоста,
поведінки за замовчуванням при DMA-мапінгу і кількості зміни відображень в IOMMU при інтенсивному I/O.

Ось чому iommu=pt може допомагати навіть якщо ви не робите повний PCI passthrough. Деякі навантаження створюють масивну
активність map/unmap для DMA (мережеві стеки, сховище, обробка пакетів у userspace, певні GPU/акселераторні драйвери).
Якщо ці шляхи заходять до IOMMU у translated mode, ви платите CPU-циклами, тиском на кеш, IOTLB-інвалідаціями і
інколи «чому ksoftirqd їсть мій процесор».

Практичне уявлення:
iommu=pt обмінює частину стандартної ізоляції на зменшені витрати на трансляцію й облік.
Це регулятор продуктивності з прив’язаним рахунком за безпеку та налагодження.

Два терміни, які плутають: «IOMMU увімкнено» vs «DMA remapping увімкнено»

На багатьох платформах у прошивці бачите нечіткі перемикачі: «IOMMU», «VT-d», «DMA remapping», «SVM», «AMD-Vi».
Часто можна мати увімкнені розширення віртуалізації, коли DMA remapping вимкнено. Гості все одно запускаються, але ізоляція пристроїв і
безпечний passthrough стають проблемними. На Linux intel_iommu=on (або amd_iommu=on) може примусити увімкнення, тоді як
iommu=off вимикає його в ядрі.

Важливо тримати це в голові, бо симптоми схожі: зміни продуктивності, VFIO перестає працювати або логи ядра заповнюються скаргами DMAR/IOMMU.
Але виправлення різні.

Точна цитата (парафраз, бо точність важлива)

Парафразована ідея (приписується Gene Kim): «Робота над покращенням має бути прив’язана до результатів, і потрібні петлі зворотного зв’язку достатньо швидкі, щоб керувати процесом».

Навіщо потрібен IOMMU: коротка історія з гострими краями

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

Цікаві факти та контекст (8 пунктів)

IOMMU з’явилися до сучасного хайпу віртуалізації. Спочатку вони були важливі для систем, яким потрібно було DMA-писання в пам’ять за межами адресного простору пристроїв, і для перенаправлення в складних шинних топологіях.
Intel VT-d і AMD-Vi формалізували DMA remapping як системну можливість. Це було критично для безпечного призначення пристроїв в VM: без DMA-ізоляції «passthrough» означає «будь ласка, малюй по моєму гіпервізору».
Ранній PCI passthrough був крихким через проблеми з перериваннями і DMA-ізоляцією. MSI/MSI-X, ремапінг і коректна ізоляція IOMMU-груп були частиною робіт над тим, щоб це стало буденністю.
Linux DMA API абстрагував мапінг, але бекенд IOMMU може робити його дорогим. Драйвери викликають API мапінгу і очікують, що це «достатньо дешево». Під навантаженням «достатньо дешево» стає дискусією.
IOTLB існує, бо пристрої теж кешують трансляції. Коли відображення змінюються, потрібно інвалідувати кеши; шторми інвалідацій реальні і проявляються як стрибки затримки.
SR-IOV змінив радіус ураження. Тепер може бути багато VFs (віртуальних функцій), кожна з власними потребами в мапінгу. Це чудово для щільності. І чудово для знаходження повільних шляхів.
Користувачі з високою частотою пакетів у userspace (DPDK, XDP, AF_XDP) тиснуть на стратегію мапінгу. Фіксація пам’яті й використання hugepages — це не лише про уникнення TLB-misses, а й про зменшення зміни відображень.
Дослідження безпеки зробили DMA-атаки мейнстримом. «Зловмисний периферійний пристрій» — не лише сюжет шпигунського фільму; це реальна загроза в мультиорендних середовищах і там, де можливий фізичний доступ.

Жарт №1 (короткий, релевантний): IOMMU — це як швейцар для вашої оперативки. Дорогий, але не дає мережевому адаптеру шукати VIP-зони.

Хто повинен використовувати `iommu=pt` (а кому краще триматися подалі)

Ось упереджена версія: використовуйте iommu=pt, коли ви можете виміряти накладні витрати IOMMU і контролювати радіус ураження.
Не використовуйте його тільки тому, що прочитали коментар на форумі «вирішило проблему у мене».

Хороші кандидати

Виділені хости віртуалізації з VFIO passthrough, де більшість пристроїв належать хосту, і ви хочете зменшити стандартні
накладні витрати DMA-трансляції для пристроїв хоста.
Вузли з високою частотою пакетів, які використовують SR-IOV, DPDK, AF_XDP або важкий virtio-net з vhost-акселерацією, де ви перевірили, що час витрачається на мапінг/розмапінг або IOTLB-інвалідації.
Гіпервізори, орієнтовані на сховище, з великою кількістю завершень NVMe, черг і роботи з перериваннями, де цикли CPU, витрачені на DMA-мапінг, вимірюються й шкодять tail-latency.
Середовища з одним орендарем, де модель загроз — операційні помилки, а не зловмисний DMA.

Погані кандидати

Мультиорендні або ворожі середовища, де DMA-ізоляція є частиною вашої політики безпеки. Ви все ще можете використовувати IOMMU і VFIO безпечно, але «пасстру за замовчуванням» — це політичний вибір. Приймайте його свідомо.
Хости, що покладаються на сувору DMA-ізоляцію навіть для пристроїв хоста (думайте: недовірені периферії, hotplug, edge-локації, лабораторії з таємничим залізом).
Системи, де налагодження вже складне. Якщо ви живете в болоті періодичних I/O-проблем, зменшення ізоляції може перетворити «періодичне» на «нерепродуковане».

Якщо ви думаєте «але ми не мультиорендні», пам’ятайте: ви завжди multi-stakeholder. Команди безпеки, відповідності та інцидент-реакції будуть у вашому майбутньому. Залишайте систему зрозумілою для них.

Що ви здобуваєте і що ризикуєте

Плюси: звідки береться продуктивність

IOMMU додає роботи кількома шляхами:

Накладні витрати на мапінг: ядро (або драйвер) має створювати IOVA-відображення для DMA. Під навантаженням це облік, що коштує CPU.
IOTLB-інвалідації: коли відображення змінюються, пристрої й IOMMU потребують інвалідацій; вони можуть серіалізуватися і викликати стрибки затримки.
Менші ефективні DMA-вікна: погані значення за замовчуванням можуть спричиняти фрагментацію в просторі IOVA або змушувати використовувати bounce buffers.
Взаємодія з ремапінгом переривань: на деяких платформах ремапінг переривань прив’язаний до увімкнення IOMMU; конфігурація може впливати на доставку переривань і їхню вартість.

iommu=pt зменшує роботу мапінгу для «звичних» пристроїв хоста, віддаючи перевагу ідентичним відображенням. Це може:

Знизити витрати CPU на критичних I/O шляхах.
Зменшити tail-latency, викликану інвалідаційною метушнею.
Зробити деякі навантаження менш чутливими до невеликих змін відображень.

Мінуси: що ви можете поламати (або послабити)

Зміни в безпековій позиції: ви можете втратити стандартний DMA-захист для деяких пристроїв. Якщо пристрій поводиться неправильно (баг або зловмисне), він легше зможе звертатися до пам’яті хоста.
Складність налагодження зростає: сувора трансляція ловить певні класи багів драйверів/пристроїв (помилкові DMA-адреси). Ідентичні відображення можуть дозволити їм тихо «писати».
Припущення в інструментах: деякі середовища припускають, що «IOMMU увімкнено» означає «DMA хоста захищено». З passthrough за замовчуванням це припущення стає хибним, якщо ви не забезпечите пер-пристрій трансляцію там, де потрібно.
Кукурудзяні апаратні курйози: деякі чіпсети і пристрої поводяться інакше з passthrough за замовчуванням, особливо щодо ATS/PRI-функцій, ремапінгу переривань або дивної поведінки прошивки.

Жарт №2 (короткий, релевантний): Зміна режимів IOMMU в продакшні — як реорганізація дата-центру під час тренування пожежної тривоги — пізнавально, але ви вивчите нові слова.

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

Ви не вмикаєте iommu=pt, бо вам нудно. Ви вмикаєте його, бо маєте вузьке місце і можете його пояснити.
Ось порядок операцій, який я використовую, коли хост віртуалізації «швидкий, окрім тих моментів, коли ні».

Перший крок: доведіть, що проблема — CPU-час, затримка чи черги

Шукайте насичення CPU у softirq, kvm, vhost або роботі, пов’язаній з iommu.
Шукайте стрибки tail-latency, корельовані з перериваннями мережі/сховища.
Шукайте зростання глибини черг: кільця NIC, черги NVMe, blk-mq, черги vhost.

Другий крок: підтвердіть, чи IOMMU в шляху і як він налаштований

Чи увімкнений IOMMU у прошивці й ядрі?
Використовується translated mode глобально чи passthrough за замовчуванням?
Чи критичні пристрої (призначені VFIO) все ще ізольовані належним чином?

Третій крок: ідентифікуйте гарячий шлях (мапінг/розмапінг проти іншого)

Зніміть профіль perf для iommu_map/iommu_unmap та функцій DMA API.
Перевірте витрати на IOTLB-інвалідації.
Перевірте використання bounce buffering / swiotlb, що часто вказує на обмеження адресування/мапінгу.

Ключовий вибір

Якщо ви можете показати значущий CPU-час у DMA-мапінгу або IOMMU-інвалідаціях на хості — і модель безпеки це дозволяє — тоді
iommu=pt є виправданим експериментом. Якщо ви цього не можете показати, ви ймовірно оптимізуєте плацебо.

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

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

Завдання 1: Підтвердьте командний рядок ядра (що ви фактично завантажили)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0 root=UUID=... ro quiet intel_iommu=on iommu=pt

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

Завдання 2: Перевірте dmesg на режим IOMMU і ініціалізацію DMAR/AMD-Vi

cr0x@server:~$ dmesg -T | egrep -i 'DMAR|IOMMU|AMD-Vi|iommu=' | head -n 30
[Mon Feb  3 10:11:21 2026] DMAR: IOMMU enabled
[Mon Feb  3 10:11:21 2026] DMAR: Default domain type: Passthrough
[Mon Feb  3 10:11:21 2026] pci 0000:00:00.0: DMAR: Skip IOMMU disabling for graphics

Значення: «Default domain type: Passthrough» — це явний доказ, що iommu=pt подіяв (на шляхах Intel VT-d).
Рішення: Якщо ви цього не бачите, можливо ви на іншому драйверному шляху, прошивка могла відключити функції, або параметр ігнорується.

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

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/7/devices/0000:3b:00.0

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

Завдання 4: Огляньте групу конкретного пристрою (поділяється чи приклеєний до друзів?)

cr0x@server:~$ lspci -nn | egrep -i 'Ethernet|Non-Volatile|VGA' | head -n 5
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
5e:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:3b:00.0/iommu_group
/sys/kernel/iommu_groups/7

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups/7/devices/
0000:3b:00.0
0000:3b:00.1

Значення: NIC має дві функції в одній групі; це звично. Passthrough вимагає, щоб всю групу контролювали разом.
Рішення: Якщо група містить несумісні пристрої, можливо знадобиться інше розміщення в слотах PCIe, налаштування BIOS ACS або прийняти «немає passthrough».

Завдання 5: Перевірте, чи використовується VFIO і які пристрої прив’язані

cr0x@server:~$ lsmod | egrep 'vfio|kvm|vhost' | head -n 20
vfio_pci               73728  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   53248  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             376832  0
kvm                  1097728  1 kvm_intel
vhost_net              32768  0

cr0x@server:~$ lspci -nnk -s 3b:00.0
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Ethernet Converged Network Adapter X710 [8086:0000]
	Kernel driver in use: vfio-pci
	Kernel modules: i40e

Значення: NIC прив’язано до vfio-pci; для гостя має бути використана трансляційна ізоляція навіть якщо домен за замовчуванням passthrough.
Рішення: Якщо пристрій, який мав би бути для хоста, випадково прив’язано до vfio, очікуйте відсутності мережі/сховища на хості і дуже напруженої зустрічі.

Завдання 6: Перевірте домен за замовчуванням IOMMU (загальний інтерфейс, коли доступний)

cr0x@server:~$ cat /sys/module/iommu/parameters/default_domain
pt

Значення: Домейн за замовчуванням ядра IOMMU — passthrough.
Рішення: Якщо написано translated (або схоже), ви не в тому режимі, в якому думаєте; перевірте параметри ядра та дефолти дистрибутива.

Завдання 7: Шукайте використання SWIOTLB (класичний прихований донор продуктивності)

cr0x@server:~$ dmesg -T | egrep -i 'swiotlb|bounce' | head -n 20
[Mon Feb  3 10:11:20 2026] software IO TLB: mapped [mem 0x000000007a000000-0x000000007e000000] (64MB)

Значення: SWIOTLB — це механізм bounce buffer. Він може з’явитись через обмеження адресування DMA, конфігурацію IOMMU або апаратні курйози.
Рішення: Якщо ви бачите інтенсивне використання SWIOTLB під навантаженням (часто видно в perf), розгляньте розміщення пам’яті, BIOS-налаштування «above 4G decoding» або тюнінг IOMMU.

Завдання 8: Перевірте, чи увімкнено ремапінг переривань (впливає на стабільність і безпеку)

cr0x@server:~$ dmesg -T | egrep -i 'Interrupt remapping|IR:' | head -n 20
[Mon Feb  3 10:11:21 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Значення: IRQ remapping увімкнено. Добре для ізоляції і іноді необхідно для стабільного passthrough на деяких системах.
Рішення: Якщо воно вимкнене неочікувано, перевірте налаштування прошивки та параметри ядра; деякі платформи вимикають його при дивній конфігурації.

Завдання 9: Профілювання гарячих точок IOMMU/DMA (доказ перед політикою)

cr0x@server:~$ sudo perf top -g --call-graph fp
Samples: 18K of event 'cycles', Event count (approx.): 12200542319
  5.21%  [kernel]  [k] iommu_map
  4.87%  [kernel]  [k] iommu_unmap
  3.94%  [kernel]  [k] dma_map_page_attrs
  3.12%  [kernel]  [k] intel_iommu_unmap
  2.77%  [kernel]  [k] handle_edge_irq

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

Завдання 10: Перевірте CPU-час хоста у softirq (часто виявляється мережевий біль)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server) 	02/03/2026 	_x86_64_	(64 CPU)

12:14:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:14:02 AM  all   12.5  0.0  18.2   0.4  0.8  22.9   0.0  45.2
12:14:02 AM    7    8.1  0.0  15.0   0.0  1.2  46.3   0.0  29.4

Значення: Високий показник %soft часто вказує на мережеву або блочну роботу завершень і роботу, керовану перериваннями.
Рішення: Якщо softirq високий і perf показує функції IOMMU, шлях мапінгу є кандидатом; якщо softirq високий, а IOMMU ні — зосередьтеся на NIC/RPS/IRQ affinity.

Завдання 11: Підтвердьте поведінку hugepages та pinned memory (особливо для DPDK/VFIO)

cr0x@server:~$ grep -E 'HugePages|Hugepagesize' /proc/meminfo
HugePages_Total:     4096
HugePages_Free:      3900
HugePages_Rsvd:       120
Hugepagesize:       2048 kB

Значення: Hugepages доступні; це знижує тиск на TLB і може зменшити зміну відображень у userspace I/O фреймворках.
Рішення: Якщо ви покладаєтеся на hugepages і вони витрачаються під навантаженням, ви побачите колапс продуктивності, схожий на «IOMMU повільний».

Завдання 12: Перевірте поведінку процесів QEMU/KVM та потоків CPU (не звинувачуйте IOMMU за pinned vCPU)

cr0x@server:~$ ps -eo pid,comm,pcpu,psr,cls,rtprio,pri,ni,stat --sort=-pcpu | head
 23144 qemu-system-x86 189.7  12  TS      -  19   0 Rl
  1821 ksoftirqd/7       45.2   7  TS      -  19   0 R
  1402 vhost-23144       32.1   7  TS      -  19   0 R

Значення: Процес VM і vhost-потік гарячі, плюс ksoftirqd на тому ж CPU.
Рішення: Перед тим як чіпати IOMMU, виправте CPU affinity і розподіл IRQ. Якщо все тримати на CPU 7, ви створили маленьку пробку.

Завдання 13: Проаналізуйте розподіл IRQ для NIC (шторми переривань маскуються під «накладні витрати IOMMU»)

cr0x@server:~$ egrep -i 'eth0|i40e|x710' /proc/interrupts | head -n 10
 169:  12499231   38123   11212   11098   IR-PCI-MSI 524288-edge      eth0-TxRx-0
 170:  12588110   39001   11992   10902   IR-PCI-MSI 524289-edge      eth0-TxRx-1

Значення: Переривання є і розподілені між CPU (перші колонки). Якщо всі лічильники на одному CPU, ви знайшли ймовірну причину затримки.
Рішення: Якщо розподіл поганий, налаштуйте IRQ affinity і RPS/XPS; iommu=pt не врятує від накопичення переривань на одному ядрі.

Завдання 14: Перевірте на помилки IOMMU (коли проблеми продуктивності — насправді помилки)

cr0x@server:~$ dmesg -T | egrep -i 'IOMMU fault|DMAR: DRHD|IO_PAGE_FAULT|AMD-Vi: Event logged' | tail -n 10
[Mon Feb  3 12:19:04 2026] DMAR: [DMA Read] Request device [3b:00.0] fault addr 0x7f3a4000 [fault reason 0x05] PTE Read access is not set

Значення: Реальна DMA-помилка. Це не «час тюнінгу», це «час ізоляції та коректності».
Рішення: Зупиніться. Підтвердіть призначення пристрою, стабільність драйвера, прошивку і чи гість/хост неправильно налаштовані. iommu=pt може приховати це, а не виправити.

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

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середня SaaS-компанія експлуатувала флот KVM гіпервізорів зі змішаними virtio-пристроями і кількома VFIO passthrough NIC для «преміум» орендарів.
Безпека погодила «IOMMU увімкнено» як частину чекліста жорсткої політики. Інфраструктурна команда почула ту саму фразу і переклала її як
«ми можемо безпечно робити passthrough; IOMMU увімкнено».

Новий rollout ядра включав iommu=pt. Його додали як оптимізацію після лабораторного тесту, який показав зниження використання CPU в мережевих навантаженнях.
Зміна в нотатці була «тримає IOMMU увімкненим, покращує продуктивність». Усі кивають головами. Ніхто не запитав: «які саме пристрої досі отримують translated domains за замовчуванням?»

Через кілька тижнів вони розслідували дивну корупцію пам’яті хоста. Нерегулярно. Нерепродуковане. Така проблема, що змушує пити холодну каву.
Після достатньої археології логів команда знайшла закономірність: уражені хости мали конкретний out-of-tree драйвер для контрольної PCIe-картки.
Та картка DMA-писала не в ті адреси при певних умовах ресету. У строгому translated mode це б голосно впало з fault. У passthrough за замовчуванням це писало тихо.

Виправлення було не «ніколи не використовувати iommu=pt». Виправлення — припинити трактувати «IOMMU увімкнено» як булеву контрольну точку.
Вони замінили проблемну картку/драйвер і посилили контроль змін навколо параметрів ядра, що впливають на DMA-ізоляцію.
Також додали перевірку після завантаження, яка верифікує домен за замовчуванням і оповіщає про неочікувані зміни.

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

Підприємство експлуатувало інфраструктуру низької затримки для трейдингу на виділених хостах. Вони не були мультиорендними, але вкрай чутливими до джиттера.
Інженер продуктивності побачив мапінг/розмапінг у профілі і вирішив «повністю прибрати накладні витрати IOMMU». Вони задали iommu=off по всьому флоту.
Початковий бенчмарк виглядав чудово. Керівництво отримало бажаний графік.

Потім вікно оновлення привело до прошивок NIC. Один хост повернувся з трохи іншою топологією PCIe і дивним курйозом у поведінці переривань.
Без ремапінгу переривань (часто пов’язаного з увімкненням IOMMU) вони отримали періодичні шторми переривань і пропуски переривань під навантаженням.
Симптом був простий: періодична втрата пакетів на межі хоста.

Вони намагалися налаштувати кільця, коалесценцію, IRQ affinity — звичні важелі. Іноді допомагало, іноді ні.
Справжня проблема полягала в тому, що платформа опинилася в менш-тестованій конфігурації для того поєднання NIC/прошивки.
Це не був «баг Linux», а «ви вимкнули функцію, яку очікує платформа» баг.

Вони повернулися до intel_iommu=on iommu=pt. Продуктивність залишилася хорошою, стабільність повернулася.
Урок не в тому, що IOMMU завжди добрий. Урок у тому, що платформа — це система. Вилучіть одну частину — інші можуть засмутитися.

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

Команда хмари експлуатувала приватну платформу віртуалізації для внутрішніх навантажень: CI-ранери, бази даних і кілька GPU-хостів для ML.
Вони мали сувору політику «одна зміна за деплой» для параметрів ядра. Це дратувало розробників. Але це їх і врятувало.

Коли вони експериментували з iommu=pt, не почали з rollout. Вони почали з інструментування:
профілі perf під репрезентативним навантаженням, гістограми латентності baseline, підрахунок IOMMU-фолтів з dmesg, і
простий щоденний експорт /proc/cmdline + домену IOMMU за замовчуванням.

Тест показав невелике, але стабільне падіння CPU хоста для їхнього мережево-важкого CI-навантаження. Добре. Вони розгорнули на одному кластері.
Через два дні один GPU-хост почав викидати DMA-фолти під час ресетів гостьових систем. Команда змогла відразу корельовати проблему:
вона існувала і раніше, але у строгому режимі вона фіксувалася раніше; passthrough за замовчуванням робив відмову рідшою, але більш руйнівною.

Оскільки був staged rollout і телеметрія, відкат пройшов чисто. Без драм. Без «ми думаємо, що це ядро» руху руками.
Вони ізолювали проблему до конкретного поєднання прошивки GPU і драйвера, виправили це, а потім знову ввели iommu=pt з упевненістю.
Нудні практики не приносять оплесків. Вони приносять сон.

Типові помилки (симптом → корінь → виправлення)

1) Симптом: VFIO passthrough не працює після увімкнення `iommu=pt`

Корінь: Плутання iommu=pt з iommu=off, або прошивка фактично не увімкнула DMA remapping.
Іноді система завантажується без належної підтримки IOMMU, тож VFIO відмовляється приєднатися.

Виправлення: Перевірте через dmesg, що IOMMU увімкнено, перевірте наявність груп, переконайтесь, що встановлено intel_iommu=on або amd_iommu=on, і впевніться, що у прошивці VT-d/AMD-Vi увімкнено.

2) Симптом: продуктивність покращилась, але тепер рідкісні краші хоста або корупція пам’яті

Корінь: Багатий пристрій/драйвер DMA-писав неправильно; строгий translated mode би зафіксував це fault-ом, passthrough за замовчуванням дозволив тихо писати.

Виправлення: Розглядайте це як коректність. Оновіть прошивки/драйвери, видаліть проблемні пристрої і подумайте про збереження translated mode для певних класів пристроїв (або уникайте iommu=pt на хостах із сумнівними периферіями).

3) Симптом: стрибки затримки залишаються навіть з `iommu=pt`

Корінь: Вузьке місце не в трансляції IOMMU; воно в IRQ affinity, backlog softirq, розміщенні vhost-потоків або в драйверах на стороні гостя.

Виправлення: Використовуйте /proc/interrupts, mpstat та perf, щоб знайти справжній гарячий шлях. Виправте CPU pinning та розподіл IRQ першочергово.

4) Симптом: SR-IOV VFs працюють, але пропускна здатність нестабільна між VM

Корінь: Обмеження IOMMU-груп і ACS призводять до незручного розміщення, або у вас змішані режими переривань серед VFs.
Іноді частина VFs опиняється з іншим NUMA-локалізаціям і ви звинувачуєте IOMMU.

Виправлення: Перевірте групи, NUMA-вузол для PCI-пристроїв, розподіл IRQ, і забезпечте вирівнювання vCPU у VM з локальністю пристрою.

5) Симптом: dmesg показує DMA-фолти після зміни параметру ядра

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

Виправлення: Не «налаштовуйте це геть». Ідентифікуйте пристрій, драйвер і навантаження, що викликають фолт. Перевірте конфігурацію VFIO і оновіть прошивку.

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

Покроково: як вирішити, чи варто пробувати `iommu=pt`

Сформулюйте мету. Приклад: «Знизити CPU хоста на 10% при 2Mpps на хост з одночасним збереженням стабільності VFIO passthrough.»
Зніміть базу. Профіль perf, softirq %, p99 латентності для ключових шляхів (сховище, мережа) і підрахунок фолтів у dmesg.
Доведіть, що накладні витрати IOMMU існують. Шукайте мапінг/розмапінг і IOTLB-інвалідації в perf під реальним навантаженням.
Підтвердіть модель загроз. Один орендар? Контрольований залізо? Якщо ні, отримайте погодження безпеки і документуйте компроміс.
Розгорніть поетапно. Один хост, один пул, один кластер. Забезпечте легкий відкат.
Підтвердіть ізоляцію для VFIO-пристроїв. Переконайтесь, що призначені пристрої все ще використовують VFIO з правильними групами.
Моніторьте після зміни. Слідкуйте за DMA-фолтами, нестабільністю хоста і tail-latency.

Контрольний список впровадження: щоб зміна була чистою

Налаштуйте прошивку: VT-d/AMD-Vi і (за потреби) «Above 4G decoding» відповідно.
Встановіть параметри ядра: intel_iommu=on iommu=pt або amd_iommu=on iommu=pt, як застосовно.
Перезавантажте, потім перевірте через /proc/cmdline і dmesg.
Переконайтесь, що IOMMU-групи існують і VFIO-пристрої в правильних групах.
Повторіть базові виміри і порівняйте.

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

Видаліть iommu=pt і перезавантажте.
Підтвердіть, що домен за замовчуванням не pt (translated або дефолт дистрибутива).
Перевірте повторно прив’язки VFIO-пристроїв і функціональність гостя.
Порівняйте логи фолтів і регресію латентності/CPU з базою.

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

1) Чи вимикає `iommu=pt` IOMMU?

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

2) Коли `iommu=pt` найімовірніше допоможе?

Коли ваш хост витрачає значущий CPU-час на DMA map/unmap або IOMMU-інвалідації під реальним навантаженням — типово для вузлів з високою частотою пакетів,
великими темпами завершень сховища або фреймворків userspace I/O.

3) Чи безпечний `iommu=pt` для мультиорендних середовищ?

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

4) Чим `iommu=pt` відрізняється від `intel_iommu=on`?

intel_iommu=on примушує увімкнення Intel VT-d IOMMU. iommu=pt встановлює домен мапінгу за замовчуванням.
Часто їх використовують разом: примусити увімкнення, потім обрати passthrough як дефолт.

5) Чи покращить `iommu=pt` продуктивність virtio?

Іноді опосередковано. Сам virtio — паравіртуальний, але поведінка DMA хоста для бекінгових пристроїв і vhost-шляхи все ще можуть включати роботу IOMMU.
Вимірюйте. Якщо perf не показує накладних витрат IOMMU, не очікуйте дива.

6) Який найбільший операційний ризик від увімкнення `iommu=pt`?

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

7) Якщо продуктивність погана, чи варто просто використати `iommu=off`?

Зазвичай ні. Вимкнення IOMMU знімає захисти і може порушити VFIO, очікування ізоляції SR-IOV і поведінку ремапінгу переривань на деяких платформах.
Якщо вам потрібна продуктивність, iommu=pt — більш хірургічний інструмент, але з компромісами.

8) Як довести, що саме `iommu=pt` покращив продуктивність?

Використовуйте порівняння до/після під тим самим навантаженням: профілі perf (час мапінгу/розмапінгу), завантаження CPU і tail-latency.
Також підтвердіть, що домен за замовчуванням змінився на passthrough у dmesg або sysfs.

9) Чи може `iommu=pt` змінити IOMMU-групи пристроїв?

Ні. Групи визначаються апаратною топологією (поведінка PCIe ACS, кореневий порт), а не режимом домену за замовчуванням.
Якщо групи погані, виправляйте топологію/ACS/слотинг, а не режим мапінгу ядра.

10) Який знак, що мені взагалі не варто чіпати налаштування IOMMU?

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

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

iommu=pt — це не магічний перемикач швидкості. Це політичний вибір: тримати IOMMU увімкненим, зменшити накладні витрати трансляції там, де ізоляція не потрібна,
і прийняти, що ви змінили стандартні засоби безпеки.

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

Виконайте швидкий план діагностики і зніміть профіль perf під реальним навантаженням. Якщо IOMMU-мапінг не гарячий — зупиніться тут.
Якщо мапінг/розмапінг гарячий, протестуйте iommu=pt на одному хості. Перевірте: cmdline, dmesg домен за замовчуванням, прив’язки VFIO і відсутність DMA-фолтів.
Порівняйте CPU і tail-latency з базовими значеннями. Якщо ви не отримали значущий виграш — відкотіться і рухайтеся далі: ваше вузьке місце десь інде.
Якщо залишаєте зміни, документуйте компроміс безпеки, додайте перевірку після завантаження для домену за замовчуванням і спостерігайте dmesg за DMA-фолтами, як за своєю службою (бо так воно й є).