Чому підбір PSU — це проблема SRE, а не тільки закупівель

Підбір PSU часто сприймають як пункт у чеклисті закупівель: вибрати потужність, позначити «резервний», відправити. У продуктивних системах такий підхід дає збій з тієї ж
причини, з якої «просто додамо вузли» дає збій: ігнорує перші жорсткі обмеження, які спрацьовують.

PSU — це місце, де ваша робоче навантаження стає фізикою. Сплески навантаження перетворюються на стрибки струму. Поведінка прошивки — в енергії вентиляторів. Нова мережна карта —
це кілька ватів, на які ви ніколи не заклали бюджет. І найобразливіше: коли з харчуванням щось йде не так, симптоми не завжди кричать «харчування».
Ви отримуєте нестабільні диски, несподівані перезавантаження, скиди NIC, пошкоджені датчики BMC або «випадкові» kernel panic. Проблеми з харчуванням маскуються під софтверні.

Ви прагнете трьох результатів:

• Жодних відмов, спричинених спрацьовуванням автоматів, перевантаженням PSU чи просадками напруги.
• Жодних втрат через надмірно великі PSU, що працюють у низькоефективному режимі.
• Швидкого відновлення, коли PSU виходить з ладу, падає живлення або PDU вас обдурює.

Якщо ваш метод підбору PSU — «підсумувати TDP і округлити вгору», ви керуєте продакшеном на надії. Надія — не джерело живлення.

Цікаві факти та трохи історії (щоб ви не повторювали старі помилки)

1. Ранні ПК-блоки живлення були орієнтовані на навантаження з тяжінням на 5V. Сучасні сервери в основному 12V-центровані, а DC-DC перетворення перемістилося на плату.
2. ATX12V (початок 2000-х) перекинув більше потужності на 12V для живлення CPU, змінивши значення «рейлів» та обмежень струму в реальних збірках.
3. 80 PLUS (сер. 2000-х) зробило ефективність маркетинговою і закупівельною позицією, але його тестові точки не покривають ваші спікоподібні навантаження.
4. Дата-центри змістилися від «один великий UPS» до розподілених UPS і розумних PDU, що спростило вимірювання — якщо ви справді ними користуєтесь.
5. Резервні PSU стали стандартом не тому, що вони модні, а тому, що гаряча заміна PSU краще, ніж вікно техпідтримки о 2-й ночі.
6. Сучасні CPU і GPU ввели агресивне підвищення частоти; миттєва потужність може перевищувати «TDP» у спосіб, який закупівельні презентації рідко згадують.
7. Криві вентиляторів змінили правила гри: вентилятори з високим статичним тиском можуть споживати значну потужність на повній швидкості, а оновлення прошивки можуть змінити поведінку вночі.
8. Щільність стояків зросла із появою віртуалізації і GPU; потужність і охолодження стали першими обмеженнями, а не лише місця в стійці.
9. Координація автоматів у будівлях еволюціонувала, але автомати все ще спрацьовують швидше за ваше оповіщення — особливо щодо пускового струму.

Здорова модель мислення: середнє, пікове і кепські секунди між ними

Помилки у підборі PSU виникають через використання одного числа, коли потрібно принаймні три:

• Середньостатистичне споживання в steady-state: що сервер споживає більшу частину часу.
• Тривалий пік: що він споживає під реальною роботою, не за синтетичною «TDP»-логікою.
• Транзієнт/пусковий струм: що він споживає під час завантаження, одночасного запуску дисків, розгону вентиляторів або стрибків GPU.

Додайте четверте, якщо використовуєте резервування:
режим з одним PSU — бо в конфігурації 1+1 вам все одно треба вижити на одному PSU без колапсу.

Що насправді означає «потужність PSU»

«1200W» PSU зазвичай сертифікований для певної вхідної напруги, температури, повітряного потоку і іноді висоти над рівнем моря. Це також означає максимальний DC-вихід за тих умов.
Це не означає, що ваша система безпечно може безперервно споживати 1200W у будь-якій стійці, за будь-якої температури і поки пил накопичується в корпусі як утеплювач.

Цитата, яку варто мати на стіні

«Надія — не стратегія.» — Gen. Gordon R. Sullivan

Не SRE, але сенс болісно релевантний. У плануванні живлення «ймовірно, не піде в пік» — це надія, переодягнена в інженерію.

Жарт №1: PSU сервера — як парашут: якщо ви дізнаєтеся, що він замалий тільки коли він потрібен, у вас буде поганий день.

Що вимірювати (і що специфікації вам не скажуть)

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

Вимірюйте на кількох рівнях

• Вхідна потужність на стіні / PDU: за що ви платите і що може спровокувати спрацьовування автомата.
• Вихід PSU (рідко безпосередньо видимий): що система споживає у термінах DC.
• Підказки на рівні компонентів: потужність пакета CPU, GPU, активність дисків, оберти вентиляторів та PWM.

Знайте обмеження, які важливі

• Гілковий ланцюг (рейтинг автомата; практика дерейтингу для безперервного навантаження відрізняється по регіонах і кодексу).
• Обмеження PDU і вилки (C13/C14 vs C19/C20, перетин кабелю, ліміти на вихід).
• Номінал PSU на вашу вхідну напругу (поширена пастка: 120V vs 208/230V — продуктивність і доступний запас різняться).
• Режим резервування (розподіл навантаження vs активний/резервний; і чи витримає платформа один PSU при повному навантаженні).

Не плутайте ці терміни

• TDP: точка теплового проєктування, а не контрактне обмеження потужності.
• PL1/PL2 (та еквіваленти вендорів): тривале проти boost-політики потужності; прошивка може їх змінити.
• Уявна потужність (VA) vs реальна потужність (W): UPS і PDU можуть показувати одне або інше; коефіцієнт потужності важливий, коли ви близькі до лімітів.

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

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

Завдання 1: Прочитати миттєву потужність, що її повідомляє BMC (IPMI)

cr0x@server:~$ ipmitool sensor | egrep -i 'Power|Pwr Consumption|Watts'
Pwr Consumption   | 312        | Watts      | ok

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

Завдання 2: Витягнути історію потужності / min-max якщо платформа це експонує

cr0x@server:~$ ipmitool sdr elist | egrep -i 'Pwr|Power'
System Level      | 00h | ok  |  3.1 | Power Meter
System Level      | 01h | ok  |  3.2 | Power Max
System Level      | 02h | ok  |  3.3 | Power Min

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

Завдання 3: Виміряти обмеження потужності пакета CPU і струм (Intel RAPL через powercap)

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
225000000

Значення: 225,000,000 µW = 225W довготривале обмеження пакета (PL1-подібне) для цього домену RAPL.
Рішення: Якщо ваш підбір PSU базувався на «CPU 165W», але прошивка дозволяє 225W тривало, оновіть бюджет або встановіть обмеження.

Завдання 4: Виміряти енергію RAPL для оцінки середнього споживання CPU за інтервал

cr0x@server:~$ E1=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); sleep 10; E2=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); echo $(( (E2-E1)/10000000 ))
186

Значення: Приблизно 186W в середньому для того пакета за 10 секунд (енергія в µJ поділена на 10s).
Рішення: Ідентифікуйте навантаження з тривалим високим споживанням CPU — саме вони роблять «пік» не рідкісною подією.

Завдання 5: Перевірити споживання GPU і ліміти (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,power.draw,power.limit,clocks.sm --format=csv,noheader
NVIDIA A10, 126.54 W, 150.00 W, 1395 MHz

Значення: Реальне споживання GPU 126W з лімітом 150W.
Рішення: Для GPU-серверів підбір PSU без реальної телеметрії GPU — це показуха. Якщо кілька GPU можуть одночасно досягти ліміту, закладайте цей пік.

Завдання 6: Перевірити поточну частоту CPU і статус тротлінгу (швидка перевірка)

cr0x@server:~$ lscpu | egrep -i 'Model name|CPU max MHz|CPU MHz'
Model name:          Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:         3200.0000
CPU MHz:             2001.102

Значення: Поточна частота не підвищена; під навантаженням вона може різко зрости і збільшити потужність.
Рішення: Якщо ви бачите постійно низьку частоту під навантаженням, можливо, у вас обмеження по живленню або термальне обмеження — обидва пов’язані з PSU і охолодженням.

Завдання 7: Перевірити журнали ядра на події, пов’язані з живленням

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'power|brown|thrott|vrm|PSU|over current|watchdog' | tail -n 20
kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: b200000000070005
kernel: EDAC MC0: CPU power throttling detected

Значення: Апаратура/прошивка повідомили про тротлінг або помилки, які можуть бути пов’язані з доставкою живлення (не завжди, але варто корелювати).
Рішення: Якщо це корелює зі сплесками або перезавантаженнями, припиніть шукати «випадкову нестабільність» і перевірте живлення, PSU і терміку.

Завдання 8: Перевірити статус PSU і режим резервування через IPMI (якщо підтримується)

cr0x@server:~$ ipmitool sdr type 'Power Supply'
PS1 Status       | ok
PS2 Status       | ok
PS1 Input Power  | 165 Watts
PS2 Input Power  | 162 Watts

Значення: Обидва PSU активні і приблизно рівномірно ділять навантаження.
Рішення: Якщо ви очікували режим 1+1 з одним активним і одним в резерві, можливо ви не в тому режимі резервування, який думаєте. Оновіть модель відмови.

Завдання 9: Виміряти потужність від стіни через метрований Rack PDU (приклад SNMP)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.7.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.7.1 = INTEGER: 356

Значення: OID вендора повертає потужність на розетці в ватах (приклад: 356W). Семантика MIB відрізняється; підтвердіть одиниці виміру один раз, а потім автоматизуйте.
Рішення: Використовуйте показники PDU як істину для планування ланцюгів і ризику автомату. Показники BMC — «приємні для перегляду», але не ваш фінансовий орієнтир.

Завдання 10: Перевірити струм на виході PDU, щоб виявити ризик близький до спрацьовування

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.5.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.5.1 = INTEGER: 28

Значення: Струм на розетці (приклад: 2.8A якщо пристрій використовує декаампера); знову ж таки, залежить від вендора.
Рішення: Переведіть у ампери, порівняйте з лімітами ланцюга та PDU. Якщо ви близько — не додавайте «ще один вузол».

Завдання 11: Корелювати навантаження з потужністю за допомогою контрольованого тесту навантаження (CPU)

cr0x@server:~$ sudo apt-get -y install stress-ng
...
cr0x@server:~$ stress-ng --cpu 32 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info:  [8421] dispatching hogs: 32 cpu
stress-ng: metrc: [8421] cpu                60.00s  19184.12 bogo ops/s

Значення: Ви створили відтворюване навантаження на CPU. Паралельно знімайте показники PDU/BMC.
Рішення: Побудуйте для платформи «CPU-only пік» як базову величину. Потім робіть те саме з диском і мережею, щоб побачити комбіновані піки.

Завдання 12: Активність дисків і кількість приводів важливі — виміряйте це (нагрузка на сховище)

cr0x@server:~$ iostat -dx 2 3
Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await  svctm  %util
nvme0n1         820.0   110.0   128.0    24.0     358     2.10   2.1   0.6   55.0

Значення: Сховище виконує реальну роботу. Диски і контролери споживають більше під навантаженням; HDD також мають стрибки під час старту.
Рішення: Якщо ваш пік потужності співпадає з відновленнями/реконструкціями, закладайте «потужність режиму відмови», а не тільки щасливого шляху.

Завдання 13: Перевірити події заряджання батареї/модуля кеш-контролера

cr0x@server:~$ sudo dmesg | egrep -i 'battery|cachevault|supercap|charging' | tail -n 20
megaraid_sas 0000:3b:00.0: CacheVault charging started

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

Завдання 14: Перевірити оберти вентиляторів і PWM — вентилятори не безкоштовні

cr0x@server:~$ sudo ipmitool sdr | egrep -i 'FAN|RPM' | head
FAN1            | 7800   | RPM  | ok
FAN2            | 8100   | RPM  | ok

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

Завдання 15: Перевірити вхідну напругу PSU (бо 120V vs 208V має значення)

cr0x@server:~$ ipmitool sensor | egrep -i 'Inlet|VIN|AC|Voltage' | head
PS1 Inlet Volt   | 208        | Volts     | ok
PS2 Inlet Volt   | 208        | Volts     | ok

Значення: PSU бачать 208V, що зазвичай покращує ефективність і зменшує струм при однаковій потужності.
Рішення: Якщо ви на 120V і збільшуєте щільність, подумайте про переведення на вищу напругу живлення там, де це можливо. Це часто найпростіший спосіб збільшити потужність.

Завдання 16: Швидкий і грубий спостережний тест пускового струму через лог піків PDU (якщо підтримується)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.4.3.1.6.1
SNMPv2-SMI::enterprises.318.1.1.26.4.3.1.6.1 = INTEGER: 47

Значення: Лічильник «пік струму з моменту останнього скидання» (приклад). Точний OID залежить від вендора і моделі.
Рішення: Якщо піковий струм значно вищий за установившийся, рознесіть завантаження і уникайте синхронного підключення після відключень.

Резервні PSU: 1+1 не завжди означає 1+1

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

• Потужності на один PSU порівняно з піковими потребами системи.
• Поведінки розподілу навантаження (active/active або active/standby).
• Поводження при обмеженні потужності, коли один PSU відсутній (деякі системи автоматично тротлять; інші просто падають).
• Незалежності живлення (два PSU на одному PDU — це не резервування; це оптимізм із зайвими кроками).

Простими словами про N+1

Якщо у вас два 800W PSU у конфігурації 1+1, важливе питання:
Чи може сервер працювати на піку на одному 800W PSU?
Якщо реальний виміряний пік — 780W біля стіни і PSU при високій вхідній температурі дерейтується, ви не «в безпеці». Ви стоїте на тонкому технічному розрахунку.

Балансування навантаження не гарантоване

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

Пусковий струм (inrush): автоматові байдуже ваші таблиці

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

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

Жарт №2: Автомати як інженери on-call: вони багато чого терплять, але пам’ятають саме ту одну останню соломинку.

Як зменшити ризик inrush

• Рознесіть завантаження (PDU, зовнішня автоматизація або гачки оркестратора).
• Уникайте синхронного розгону вентиляторів шляхом оновлення прошивки у контрольованих хвилях, а не «всі разом у п’ятницю».
• Знайте поведінку HDD: параметри staggered spin-up на HBA збережуть ваш автомат і гордість.
• Вимірюйте піковий струм там, де можливо: деякі метровані PDU і UPS ведуть логи пікiв та inrush-подій.

Дереатинг: температура, висота над рівнем моря, пил і чому «1200W» інколи фантазія

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

Дереатинг проявляється як:

• Менший доступний вихід при вищій температурі на впуску.
• Збільшена потужність вентиляторів (що підвищує системне споживання і знижує ефективність).
• Раніше термозахистне вимкнення або захисне тротлінгування.

Температура — множник ризику

Сервер, що «в нормі» при 18°C на впуску, може стати крихким при 30°C на впуску, коли один PSU виходить з ладу, а залишений працює гарячіше і голосніше.
Саме в такий момент найгірше дізнатися, що ваша припущення про резервування базувалося на лабораторному буклеті.

Висота над рівнем моря — це реальна річ (так, правда)

На великій висоті зменшується густина повітря, а отже і ефективність охолодження. Багато вендорів вказують дереатинг вище певної висоти. Ігнорувати це можна, але PSU не переконаєте вашою впевненістю.

Криві ефективності: вати, які ви не витягуєте, все одно коштують вам

Ефективність — це не константа. Це крива. Більшість PSU «щасливі» десь на 40–60% навантаження, залежно від конструкції. При дуже низькому навантаженні ефективність падає,
і ви втрачаєте потужність у вигляді тепла. При дуже високому навантаженні ефективність теж може падати, і терміка стає некрасивою.

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

• Capex: моделі PSU більшої потужності коштують дорожче.
• Opex: нижча ефективність на холостому ходу по всьому парку — неприємно для рахунку за електрику.
• Охолодження: втрачені вати перетворюються на тепло, яке ваш об’єкт має відвести.

Що робити замість сліпого oversizing

Виміряйте реальний пік і виберіть PSU так, щоб:

• Ваш середній режим знаходився в ефективній частині кривої.
• Ваш тривалий пік залишався нижче консервативного порогу (особливо в режимі N+1).
• Ваш inrush не спрацьовував гілкові автомати під час масових подій у флоті.

Це менш гламурно, ніж купувати найбільший доступний блок. Але саме так ви уникнете проведення вихідних у холодному коридорі з ліхтариком.

Три корпоративні міні-історії з краю «має бути нормально»

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

Компанія розгорнула нову партію серверів з великим сховищем: багато дисків, подвійні контролери і «резервні» PSU. Закупівля підібрала PSU, підсумувавши TDP CPU, RAM і «трохи для дисків».
Вони також стандартизували 120V живлення в застарілій кімнаті, бо воно «вже було там».

У steady-state усе виглядало нормально. Графіки моніторингу були нудні, і розгортання оголосили успішним. Потім майже планове обслуговування електропостачання. Після відновлення живлення
весь ряд спробував завантажитися одночасно. Декілька автоматів спрацювали миттєво. Декілька стійок піднялися напівжитими: деякі сервери зациклилися на завантаженні, деякі втратили диски, а пару контролерів піднялися деградованими.

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

Причина не в тому, що сервери «споживали забагато» в середньому. Причина в тому, що inrush і одночасний запуск дисків перевищили толерантність автомата при 120V, де струм вищий при тій самій потужності.
«Резервні PSU» не допомогли, бо резервування не заважає автомату спрацювати.

Виправлення було нудним: рознесення завантаження, увімкнення staggered spin-up на HBA та переведення найщільніших стійок на вищу напругу де було можливо. Також почали фіксувати пікову потужність на PDU під час приймальних тестів.
Наступний сеанс обслуговування пройшов без пригод — а це найкращий тип події.

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

Інша організація серйозно взялася за енергоефективність і вирішила агресивно «підібрати» PSU. Вони помітили, що сервери в простое споживають близько 120–160W і вирішили, що менші PSU покращать ефективність на холостому ході.
Вони затвердили стандартну конфігурацію з низькопотужними PSU для нового обчислювального флоту.

Лабораторні тести виглядали добре. Ідл-ефективність трохи покращилася. Закупівля була в захваті через скорочення витрат. Флот розгорнули в продакшен, де навантаження було імпульсним — аналітика батчами та сплески API.
Під час сплесків поведінка CPU boost підштовхнула тривалу потужність вище, ніж очікували.

Все ще «у специфікації» для одного PSU — до тих пір, поки PSU не вийшов з ладу.

За 1+1 резервуванням один PSU повинен був нести повне навантаження. На папері це можливо. На практиці, при вищих температурах на впуску і більший запиленості, ніж в лабораторії, залишений PSU працював гарячіше.
Прошивка платформи відповіла тротлінгом продуктивності. Сервіс не впав, але затримки зросли з «добре» до «чому черга тане». SREs сприйняли це як регресію софту, бо нічого не впало. Просто стало повільно й непередбачувано.

Проблема не в самій ідеї підбору; проблема була в тому, що це робили на підставі тестів холостого ходу й ігнорували режим N+1 та дерейтинг середовища. Вирішили підняти PSU на крок, запровадити обмеження потужності для найбільш імпульсивних вузлів і припинити оцінювати успіх виключно по ефективності в idle.
Ефективність важлива. Передбачуваність важить більше.

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

Команда, що керувала змішаним флотом (GPU-коробки, ноди сховища, звичайні обчислювальні), мала скупу політику: кожна нова модель заліза мала пройти «характеризацію потужності» перед тим, як потрапити в продакшен.
Це означало вимірювання idle, 50-го процентиля навантаження, тривалого піку і пускового inrush — використовуючи той самий PDU, що й у продакшені.

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

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

Оскільки у них були початкові дані, це не стало інцидентом. Вони відкоригували розміщення в стійці (менша щільність на той ланцюг для цієї ревізії), налаштували прошивку там, де дозволено, і оновили бюджет потужності.
Місяць по тому справжній відмовник PSU стався в продакшені під важкою задачею. Вузол залишився в мережі. Жодного впливу на клієнтів. Жодних героїчних дій. Просто тиха радість нудної інженерної практики, що спрацювала як слід.

План швидкої діагностики

Коли щось пахне електропостачанням — випадкові перезавантаження, відмови, що групуються по стійці, падіння продуктивності після виходу PSU — не блукайте. Перевіряйте в цьому порядку.
Мета — знайти вузьке місце за хвилини, а не після переписування половини планувальника.

Перше: підтвердіть, що саме відмовляє (вузол, стійка, ланцюг чи кімната)

• Чи відмови групуються по стійці/PDU або по моделі заліза?
• Чи події корелюють з бойовими завантаженнями, обслуговуванням або стрибками температури?
• Чи бачите ви спрацьовування автоматів або тривоги UPS?

Друге: довіряйте PDU/UPS для вхідної потужності, потім перехресно перевірте BMC

• Перевірте PDU на рівні розетки: вати/ампери і будь-які лічильники піків.
• Порівняйте з BMC-значеннями; великі несходження вказують на погані сенсори або різні точки вимірювання.
• Підтвердіть вхідну напругу. Низька напруга означає вищий струм при тій самій потужності і менший запас.

Третє: протестуйте поведінку резервування під навантаженням

• У контрольованих умовах витягніть один PSU і спостерігайте: чи стрибне потужність? чи розженуться вентилятори? чи тротлить хост?
• Підтвердіть, що кожен PSU підключений до різних живильних вводів і що вводи справді незалежні.
• Якщо продуктивність змінюється суттєво, сприймайте це як ризик для продакшену, а не «приємний факт».

Четверте: ізолюйте транзієнтні причини

• Пусковий струм і старт дисків: шукайте події автомата або піки PDU при відновленні живлення.
• Зміни прошивки/криві вентиляторів: корелюйте з останніми оновленнями.
• Сплески навантаження: корелюйте з телеметрією CPU/GPU і часом інцидентів.

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

1) Випадкові перезавантаження під навантаженням

Симптом: Хости перезавантажуються, коли стартують пакетні задачі або сплески використання GPU.
Корінь: Перевантаження PSU або проблеми транзієнтної реакції; інколи один PSU слабкий/старіє і колапсує на крок-навантаженнях.
Виправлення: Виміряйте на PDU під час навантаження. Протестуйте з одним PSU виключеним. Замініть підозрілий PSU. Якщо піки реальні — підвищуйте потужність PSU або обмежуйте потужність.

2) Спрацьовування автоматів після обслуговування або відновлення живлення

Симптом: Цілі стійки темні, автомати спрацьовують одразу при подачі живлення.
Корінь: Пусковий струм плюс синхронне завантаження; запуск дисків і розгін вентиляторів це посилює, особливо при 120V.
Виправлення: Рознесіть завантаження. Увімкніть staggered spin-up. Знизьте щільність на ланцюг або переведіть на вищу напругу.

3) «Резервний» PSU але один вихід спричиняє падіння продуктивності

Симптом: Без відмови, але затримки зростають і пропускна здатність падає, коли один PSU помирає.
Корінь: Режим з одним PSU викликає обмеження потужності або термальний стрес; залишений PSU працює гарячим і прошивка тротлить CPU/GPU.
Виправлення: Підберіть так, щоб один PSU міг витримати тривалий пік з запасом при найгіршій вхідній температурі. Тестуйте і документуйте продуктивність у режимі відмови.

4) PDU показує високі вати, BMC — низькі (або навпаки)

Симптом: Два «авторитетних» числа розходяться на 20–40%.
Корінь: Різні точки вимірювання (вхід проти обчисленого), дрейф калібрування сенсорів або баги прошивки BMC.
Виправлення: Довіряйте PDU/UPS як істині для виставлення рахунків і автомата. Використовуйте BMC для трендів. При потребі калібруйте разом з відомим метрологічним приладом.

5) Нова прошивка спричинила перевитрату бюджету потужності

Симптом: Після оновлення BIOS/BMC вартість стійки зросла або стрибнула потужність вентиляторів; з’явилися тривоги автомата або UPS.
Корінь: Оновлені криві вентиляторів, вищі ліміти boost-потужності або інші профілі за умовчанням.
Виправлення: Повторно характеризуйте споживання після змін прошивки. Фіксуйте профілі потужності. Rollout оновлень хвилями з моніторингом PDU.

6) «Ми підібрали по TDP» і тепер усе тісно

Симптом: Математика з табличок каже, що ви в безпеці; реальні виміри говорять протилежне.
Корінь: TDP — не обмеження; накладні витрати платформи, пам’ять, диски, NIC, вентилятори і поведінка boost не були враховані.
Виправлення: Побудуйте виміряну модель потужності для кожної платформи: idle, типовий, тривалий пік, inrush і режим N+1. Припиніть використовувати суму TDP як остаточну відповідь.

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

Покроково: як підібрати PSU для моделі сервера (без гадань)

1. Визначте джерело істини для вимірювань. Для планування ємності використовуйте метрований PDU/UPS (вхідні вати); BMC — для трендів і статусу резервування.
2. Зафіксуйте умови впуску. Занотуйте вхідну напругу та приблизну температуру на впуску під час тестів. Дані потужності без умов — плітки.
3. Виміряйте чотири точки потужності:
   • Idle (після завантаження, сервіси стабільні)
   • Типове навантаження (репрезентативний продакшен-мікс)
   • Тривалий пік (стрес-тест, що імітує реальні вузькі місця)
   • Пуск/inrush (холодний старт, не теплий ребут)
4. Протестуйте поведінку N+1. Під навантаженням відключіть один PSU і спостерігайте стабільність, тротлінг і поведінку вентиляторів. Зафіксуйте потужність і терміку.
5. Застосуйте маржу свідомо. Додайте запас для помилок вимірювання, змін середовища, старіння і «сюрпризної прошивки». Уникайте миттєвої реакції «подвоїмо».
6. Перевірте відповідність ланцюгу. Переведіть вати в ампери при вашій напрузі і переконайтеся, що ви не фліртуєте з лімітом гілки під піками і inrush.
7. Визначте розмір PSU і режим резервування. Оберіть модель PSU так, щоб режим з одним PSU залишався стабільним на тривалому піку з реальним запасом.
8. Документуйте профіль. Зберігайте виміряні значення і умови тестів у вашому runbook по залізу, щоб наступна людина не займалась археологією.
9. Операціоналізуйте моніторинг. Налаштуйте оповіщення при незвичному зростанні потужності, але також при втраті резерву і несподіваних змінах в поділі навантаження.
10. Повторно тестуйте після суттєвих змін. BIOS/BMC оновлення, нові NIC/HBA, зміни моделі GPU або зсуви в навантаженнях заслуговують повторного вимірювання.

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

• На стійку: виміряний типовий і виміряний пік, а не просто сума шильдиків.
• На гілку: ампераж при фактичній напрузі з чіткими припущеннями про допустиму безперервну завантаженість.
• План по inrush: процедура рознесення завантаження задокументована і протестована.
• План резервування: PSU на різних вводах; PDU на різних upstream де можливо.
• Тести приймання: кожна нова модель заліза проходить прогін характеристик потужності перед розгортанням.

Контрольний список: версія «ми збираємося додавати GPU»

• Виміряйте ліміт потужності GPU на карту і підтвердьте загальну рамку потужності платформи.
• Підтвердіть обмеження PCIe auxiliary power і riser; не припускайте, що проводка шасі відповідає маркетингу GPU.
• Протестуйте сумарний CPU+GPU пік під реальними навантаженнями (не лише синтетичними).
• Перевірте поведінку резервування при відключенні одного PSU під GPU-навантаженням.
• Підтвердіть ланцюг і тип розетки PDU (C13 vs C19) та ліміти на розетку.

FAQ

1) Чи можу я підібрати PSU, підсумувавши TDP компонентів?

Використовуйте суму TDP лише як орієнтовний нижній межа. Реальні системи перевищують його через boost-поведінку, потужність вентиляторів, зарядні явища контролерів і транзієнти.
Вимірюйте на PDU.

2) Чи завжди купувати PSU з максимальною потужністю?

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

3) Який запас слід додати?

Однозначної величини немає. Додавайте запас для помилки вимірювання, змін середовища, старіння і майбутніх доповнень. Правильний запас — це той, що проходить режим N+1 при найгіршій вхідній температурі без тротлінгу чи нестабільності.

4) Кому довіряти більше: BMC чи PDU?

Для планування автомата і ємності: PDU/UPS вхідні вати. Для трендів по хосту і статусу резервування: BMC корисний. Якщо вони розходяться, розберіться, але бюджетуйте за PDU.

5) Чому споживання стрибає після оновлення BIOS/BMC?

Прошивка може змінити ліміти потужності CPU, криві вентиляторів, поведінку ініціалізації пам’яті і керування живленням периферії. Ставте оновлення прошивки як зміну апаратного забезпечення: повторно вимірюйте потужність.

6) Як резервні PSU впливають на ефективність?

При спільному розподілі навантаження кожен PSU працює на нижчому відсотку завантаження, що може винести вас із «солодкої точки» ефективності. При active/standby один PSU може працювати близько до солодкої точки, але інший все одно споживатиме резервну потужність.
Виміряйте, не припускайте.

7) Що таке VA vs W при підборі UPS і ланцюгів?

W — реальна потужність; VA — уявна потужність. UPS і PDU можуть вказувати одне або інше. Якщо коефіцієнт потужності далеко від 1.0, VA може бути значно вищим за W, і це може стати обмеженням для ємності UPS, навіть коли вати в нормі.

8) Як уникнути спрацьовування автоматів під час перезапусків флоту?

Рознесіть завантаження, увімкніть staggered spin-up дисків де можливо і уникайте «усі вузли одночасно вгору». Підтвердіть за допомогою логів піків PDU і проведіть контрольований тест.

9) Чи треба мені хвилюватися про ліміти рейлів PSU?

Менше ніж у старих десктопів з багатьма рейлами, але так — інколи. Серверні PSU і бэкплейни зазвичай абстрагують це, але при високій щільності GPU і розподілі riser можна наткнутися на приховані ліміти.
Якщо ви бачите нестабільність під навантаженням GPU, перевіряйте розподіл живлення платформи, а не лише сумарні вати.

10) Який практичний спосіб обмежити потужність серверів, щоб не перевищувати ліміти?

Використовуйте інструменти вендора або профілі прошивки де можливо і перевіряйте через PDU. Для CPU обмеження на базі RAPL може допомогти, але підтвердіть поведінку під вашими навантаженнями — деякі навантаження міняють затримку заради ватів у неприємний спосіб.

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

• Виберіть одну модель сервера і створіть профіль потужності: idle, типове, тривалий пік, пуск/inrush і результати тесту N+1.
• Зробіть PDU джерелом істини для вхідної потужності і піків; підключіть SNMP-опитування до вашого пайплайна метрик.
• Проведіть контрольований тест резервування: під значним навантаженням витягніть PSU і стежте за тротлінгом, розгоном вентиляторів і стрибками потужності.
• Напишіть процедуру рознесення завантаження і відрепетируйте її. Після відключення не час виявляти, що ваші інструменти не вміють секвенувати.
• Оновіть вимоги до закупівель: вимагайте метровані PSU/BMC сенсори де можливо і просіть вендорів описати поведінку в режимі одного PSU.
• Повторно перевіряйте після оновлень прошивки. Підходьте до «незначних ревізій» як до нових моделей, поки не виміряєте їх.

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

Справжній контракт оновлення: роз’єм — не означає сумісність

Люди люблять таблицю роз’ємів. «Це LGAxxxx, тож все добре.» Або «AM4 підтримує це покоління.» Це сумісність на рівні маркетингу. Сумісність на рівні продакшену гірша:

• BIOS/UEFI має розпізнати CPU (CPUID, stepping, послідовність ініціалізації, правила тренування пам’яті).
• Мікрокод має бути прийнятним (пом’якшення безпеки, обхід помилок, виправлення стабільності).
• VRM і подача живлення плати мають витримувати реальні умови (тривалий струм, реакція на перехідні вимоги, тепловий дизайн).
• Платформні ліміти потужності мають відповідати вашому навантаженню (PL1/PL2/Tau, EDC/TDC/PPT, cTDP, налаштування «auto»).
• Охолодження має відповідати поведінці boost (турбо — це так само політика тепла, як і частоти).
• ОС і гіпервізор мають правильно плануватись (нова топологія, гібридні ядра, CPPC, поведінка SMT).

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

Суха правда: в корпоративному середовищі материнська плата — це продукт, а CPU — опція, яку підтримують. У хобі-середовищі CPU — це продукт, а плата — пропозиція. Не переносіть припущення хобі у вікно змін.

BIOS проти мікрокоду проти VRM: хто насправді керує вашим CPU?

BIOS/UEFI: швейцар на вході в клуб

BIOS/UEFI — перший рівень істини. Він ініціалізує CPU, задає політики живлення, тренує пам’ять і відкриває регулятори (іноді псевдо-регулятори) для ОС. Якщо в BIOS немає правильного коду ініціалізації CPU, ви можете не завантажитися, або завантажитися з деградованою поведінкою: обмежені turbo-біни, відключені фічі або нестабільне тренування пам’яті.

Сучасні BIOS також постачаються з пакетом мікрокоду. Це важливо, бо мікрокод фактично є шаром патчів для поведінки CPU. CPU виходить з фабрики з мікрокодом, але він може бути замінений рано під час завантаження — або прошивкою, або ОС.

Мікрокод: тихий патч, який ви не тестували

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

Ви не «встановлюєте мікрокод» як драйвер. Ви розгортайте його як нове ядро: контрольовано, під моніторингом і з можливістю відкату. Якщо вам ніколи не траплялося, що оновлення мікрокоду спричинило новий цикл перезавантажень на конкретному stepping— вітаю з молодістю.

Одна цитата, яку операційні люди схильні приймати після достатньої кількості інцидентів:

«Надія — не стратегія.» — ген. Гордон Р. Салліван

VRM: та частина, на яку ви не звернули увагу, бо вона не блискуча

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

Маркетинг материнських плат говорить про «фази». Інженерів цікавить ефективна пропускна здатність струму, реакція на перехідні процеси та теплові характеристики. Плата може рекламувати багато фаз і все одно поводитися погано, якщо дизайн дешевий або погано охолоджується. У серверах VRM проєктуються під конкретні CPU SKU і валідуються з ними. У товарних платах розрив між «підтримує» і «насолоджується роботою» — там живуть ваші аварії.

Жарт №1: Оновлення CPU — як взяти більшу собаку. Повиток (VRM) ламається першим, а не сама собака.

Коротка історія та факти, що пояснюють сучасний безлад

Це не дрібниці заради дрібниць. Вони пояснюють, чому «просто поміняти CPU» постійно перетворюється на посмертну розбірку.

1. Оновлення мікрокоду існують десятиліттями, але ширше розповсюдження мікрокоду від ОС стало звичним у 2000-х, коли платформи ускладнилися і стали важливими пом’якшення безпеки.
2. Пом’якшення спекулятивного виконання після Spectre/Meltdown суттєво змінили продуктивність для деяких навантажень, особливо для систем з інтенсивними системними викликами та перемиканнями контексту.
3. Параметри потужності Intel turbo (PL1/PL2/Tau) перетворили «TDP» на політику; плати почали відвантажуватися з «необмеженими» налаштуваннями за замовчуванням, бо бенчмарки продають плати.
4. Поведінка boost і CPPC у AMD все більше залежить від координації прошивки та ОС; оновлення BIOS може змінити boost більше, ніж заміна CPU.
5. Складність тренування пам’яті зросла з вищими швидкостями DDR; версії BIOS значно відрізняються у стабільності тренування, особливо з міксованими DIMM або граничною сигналізацією.
6. Вендори серверів валідовують конкретні stepping CPU; два чіпи з тим самим SKU можуть вести себе по-різному, якщо stepping і мікрокод розходяться.
7. Теплові ліміти VRM залежать від навантаження; плата може пройти короткий бенчмарк і все одно тротлити або падати під тривалим AVX чи компресійним навантаженням.
8. Поведінка частот під AVX (пониження частоти при широких векторних навантаженнях) часто неправильно інтерпретується; «швидший CPU» може виявитися повільнішим, якщо ваш робочий навантаження провокує нижчі стійкі частоти.

Режими відмов, які ви справді побачите в продакшені

1) Завантажується нормально, а потім перезавантажується під навантаженням

Класичний випадок захисту VRM від перехідних або теплових перевантажень, або надто агресивна політика «auto» живлення. Ви побачите це при компресії, шифруванні, аналітиці з AVX або на build-серверах під паралельним навантаженням.

2) «Оновлений» CPU повільніший за старий

Поширені винуватці:

• Новий мікрокод вмикає пом’якшення, що сильніше вражає ваше навантаження.
• Ліміти потужності консервативні (PL1 зафіксовано на TDP з коротким Tau).
• Починається теплове тротлінг через іншу поведінку boost у нового CPU.
• Зміни NUMA/топології викликають неефективність планувальника (особливо у віртуальних машинах).

3) Випадкові скориговані помилки (WHEA/EDAC), які «не проблема», поки не стануть проблемою

Скориговані machine check помилки можуть вказувати на маргінальну стабільність: проблеми тренування пам’яті, граничний Vcore, провал VRM або проблеми сигналізації PCIe після зміни платформи. Продакшен любить перетворювати «скориговане» на «некориговане» під час пікового трафіку.

4) Не проходить POST, або POST лише після скидання BIOS

Це часто відсутність підтримки CPU в BIOS або регрес тренування пам’яті. Ще один трап: плати, які вимагають новішого BIOS, але не можуть прошити його без встановленого старого підтримуваного CPU. Ідеальна маленька пастка: вам потрібен CPU, щоб завантажитися і прошити BIOS, а вам потрібен BIOS, щоб завантажити CPU.

5) Осциляція продуктивності: частоти скакають, сплески латентності

Шукайте конфлікти управління живленням: governor ядра, C-states BIOS, CPPC, політики turbo або теплове тротлінг. Налаштування «auto» рідко є стабільною політикою; це тактика продажу.

6) Дивна поведінка віртуалізації після заміни CPU

Нові можливості CPU можуть змінити набір інструкцій, який видно в VM. Live migration може не пройти. Ліцензування або прапори фіч можуть зламатися. Деякі середовища вимагають маскування фіч CPU, щоб підтримувати сумісність кластера.

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

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

Перше: чи це обмеження живлення/тепла?

• Перевірте поточні та максимальні частоти під навантаженням.
• Перевірте прапори тротлінгу (якщо доступні) і датчики температури CPU.
• Зіставте тротлінг з фазами навантаження (AVX, компресія, сплески).

Друге: чи це невідповідність мікрокоду/прошивки або наслідки еррат

• Підтвердіть версію BIOS, ревізію мікрокоду і стан мікрокоду в ядрі.
• Перевірте логи на MCE/WHEA, EDAC і PCIe AER події.
• Порівняйте поведінку між ідентичними хостами — якщо лише один хост «особливий», ймовірно, справа в ньому.

Третє: чи це тренування пам’яті/стабільність IMC?

• Шукайте ECC корекції, лічильники EDAC і пам’яттєві MCE.
• Зменшіть швидкість пам’яті (або вимкніть XMP/DOCP) як тест, а не як постійне рішення.
• Запустіть контрольований memory stress тест під вікном змін, а не після.

Четверте: чи ОС-планувальник/топологія тепер неправильні?

• Підтвердіть кількість ядер, статус SMT, NUMA-вузли і налаштування ізоляції CPU.
• На гібридних архітектурах перевірте підтримку ядра і політику прикріплення.
• У віртуалізації підтвердіть маски функцій CPU і сумісність кластера.

Якщо ви не можете пояснити поведінку за 30 хвилин цими перевірками, ви перейшли з «тонкого налаштування» у «відкат і переоцінка». Це не поразка. Це дорослість.

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

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

Завдання 1: Ідентифікуйте модель CPU, stepping і ревізію мікрокоду

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Stepping|CPU\(s\)|Thread|Core|NUMA|Vendor|Flags'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
CPU(s):                          44
Thread(s) per core:              2
Core(s) per socket:              22
Socket(s):                       1
Stepping:                        1
NUMA node(s):                    1
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... avx2

Значення: Підтверджує топологію (ядра/потоки/сокети), stepping і прапори фіч. Stepping важливе для підтримки BIOS і поведінки еррат.

Рішення: Якщо stepping відрізняється від вашого валідаційного флоту, розглядайте це як новий варіант платформи. Оновіть runbook і протестуйте міграцію/маскування фіч у віртуалізації.

cr0x@server:~$ grep -m1 -E 'microcode|model|stepping' /proc/cpuinfo
model		: 79
stepping	: 1
microcode	: 0xb00003e

Значення: Показує ревізію мікрокоду, що використовується зараз.

Рішення: Якщо це відрізняється від інших хостів на тому ж BIOS/ядрі, у вас дрейф. Виправте дрейф перед тим, як звинувачувати застосунок.

Завдання 2: Перевірте версію BIOS/UEFI (і рядки вендора)

cr0x@server:~$ sudo dmidecode -t bios | egrep 'Vendor|Version|Release Date|BIOS Revision'
Vendor: American Megatrends Inc.
Version: 3.2
Release Date: 08/17/2022
BIOS Revision: 5.27

Значення: Ідентифікує прошивку, з якою ви зіставлятимете відомі хороші налаштування.

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

Завдання 3: Підтвердіть, чи мікрокод був завантажений ядром

cr0x@server:~$ dmesg -T | egrep -i 'microcode|ucode' | tail -n 5
[Tue Feb  4 10:22:11 2026] microcode: microcode updated early to revision 0xb00003e, date = 2023-10-12
[Tue Feb  4 10:22:11 2026] microcode: CPU0: patch_level=0x00000000

Значення: «updated early» означає, що мікрокод доставлений ОС (initramfs) застосований до запуску більшої частини ядра. Зазвичай це те, що ви хочете.

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

Завдання 4: Шукайте machine check помилки (MCE) та скориговані апаратні помилки

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|hardware error|whea|edac' | tail -n 20
Feb 04 10:41:12 server kernel: mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 6: b200000000070005
Feb 04 10:41:12 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000 SYND 4d000000 IPID 60000000000000
Feb 04 10:41:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Значення: MCE/EDAC записи означають, що платформа бачить і коригує (або не може коригувати) помилки. Після оновлення CPU це часто проблема тренування пам’яті або маргінального живлення/подачі енергії.

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

Завдання 5: Перевірте поведінку частот CPU і поточний governor

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Значення: Показує governor для cpu0 (зазвичай репрезентативний). «performance» утримує вищі частоти; «powersave» може все ще підвищувати частоту на сучасних CPU, але політики різняться.

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

cr0x@server:~$ grep -E 'cpu MHz|model name' -m3 /proc/cpuinfo
model name	: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
cpu MHz		: 1200.000
model name	: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz

Значення: Знімок поточної ефективної частоти. Числа в холості ході не є доказом тротлінгу; перевіряйте під навантаженням.

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

Завдання 6: Перевірте датчики температури і підказки тротлінгу

cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +76.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +77.0°C  (high = +80.0°C, crit = +100.0°C)

Значення: Якщо ви сидите на «high» під звичайним навантаженням, ви живете в боргу. Серверні CPU захищатимуть себе; ваші SLO — ні.

Рішення: Покращіть охолодження, зменшіть ліміти потужності або поміняйте SKU CPU. Не «вирішуйте» це, прикидаючись, що датчики песимістичні.

Завдання 7: Інспектуйте поведінку лімітів потужності через RAPL (Intel), коли доступно

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Power limits:
    long_term: 140.00 W (enabled)
    short_term: 180.00 W (enabled)

Значення: Показує налаштовані ліміти потужності пакета. Вони сильно впливають на стійку частоту.

Рішення: Якщо ліміти нижчі, ніж ви очікували для CPU і шасі, налаштуйте в BIOS на валідаційну політику. Якщо ваш VRM/охолодження не може витримати більше — це також відповідь.

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

cr0x@server:~$ dmesg -T | egrep -i 'thrott|thermal|power limit' | tail -n 20
[Tue Feb  4 11:02:03 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 12)
[Tue Feb  4 11:02:03 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 12)

Значення: Ядро повідомляє про події теплового тротлінгу. Це не «нормально». Це CPU, який просить менш амбітний план.

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

Завдання 9: Перевірте швидкість памʼяті та конфігурацію після оновлення

cr0x@server:~$ sudo dmidecode -t memory | egrep -A3 'Memory Device|Speed:|Configured Memory Speed:|Manufacturer:|Part Number:' | head -n 40
Memory Device
	Manufacturer: Samsung
	Part Number: M393A2K40BB1-CRC
	Speed: 2400 MT/s
	Configured Memory Speed: 2133 MT/s

Значення: Показує номінальну швидкість DIMM і налаштовану швидкість. Оновлення CPU може змінити підтримувані пам’яттєві множники або BIOS може знизити швидкість для стабільності.

Рішення: Якщо налаштована швидкість впала несподівано, перевірте підтримувані швидкості IMC CPU з вашим населенням DIMM. Стабільність важливіша за теоретичну пропускну здатність, але несподіване зниження швидкості пояснює регресії продуктивності.

Завдання 10: Перевірте помилки PCIe після змін платформи

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'aer|pcie|corrected error' | tail -n 20
Feb 04 10:55:21 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Feb 04 10:55:21 server kernel: pcieport 0000:00:1c.0: AER: [ 0] RxErr

Значення: PCIe AER скориговані помилки можуть з’явитися після змін CPU/BIOS (тренування PCIe, сигналізація, політики ASPM).

Рішення: Декілька під час завантаження можуть бути допустимі; постійні під навантаженням — ні. Досліджуйте налаштування PCIe в BIOS, перепідключіть картки, перевірте riser/кабелі і розгляньте оновлення прошивки кінцевих пристроїв.

Завдання 11: Підтвердіть NUMA-розклад і топологію CPU (важливо для регресій перфу)

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
node 0 size: 257761 MB
node 0 free: 244120 MB

Значення: Підтверджує NUMA-вузли і карту CPU. Оновлення CPU (або скидання BIOS) може змінити поведінку NUMA, інтерлевінг пам’яті або SNC (sub-NUMA clustering).

Рішення: Якщо розклад NUMA змінився від вашої базової лінії, перегляньте pinning, розподіл hugepages і припущення про локальність пам’яті.

Завдання 12: Підтвердіть експозицію функцій CPU у віртуалізації (приклад KVM)

cr0x@server:~$ sudo virsh capabilities | egrep -n 'model|vendor|feature' | head -n 25
12:    Intel
18:    Broadwell
19:    
20:    
21:    

Значення: Показує те, що хост рекламує. Після оновлення CPU модель/фічі можуть відрізнятися, що ламає сумісність live migration.

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

Завдання 13: Перевірте стан пом’якшень ядра (підказка щодо регресії продуктивності)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -n 20
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS_FW; STIBP: disabled; RSB filling

Значення: Показує, які пом’якшення активні. Мікрокод і оновлення BIOS можуть змінити це без вашого явного відома.

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

Завдання 14: Навантажувальне тестування контроловано (і дивіться помилки)

cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --metrics-brief --timeout 120s
stress-ng: info:  [27184] setting to a 120s run per stressor
stress-ng: info:  [27184] dispatching hogs: 44 cpu
stress-ng: info:  [27184] successful run completed in 120.00s
stress-ng: info:  [27184] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: info:  [27184] cpu             1234567   120.00   5100.00     12.34     10288.06

Значення: Повторюване CPU навантаження. Поєднуйте з моніторингом сенсорів і логів, щоб виявити тротлінг або помилки під час вікна.

Рішення: Якщо стрес викликає тротлінг або MCE/EDAC події, оновлення не готове для продакшену. Виправте живлення/охолодження/BIOS спочатку.

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

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

Компанія мала невеликий флот «ідентичних» 1U серверів для билд-пайплайнів. Те саме шасі, та сама ревізія плати, той самий БП. У них лежала стопка CPU для апгрейдів — швидші частини, той же роз’єм, те ж покоління. Запит на зміну сприйняли як рутинну операцію: поступове оновлення по одному хосту, без змін на рівні застосунку.

Перший оновлений хост завантажився і повернувся в пул. Біди працювали кілька годин, а потім хост жорстко перезавантажився під час пікової паралельної компіляції. Без паніки, без логів окрім останніх рядків. Він повернувся, знову впав. Команда думала, що CPU бракований і замінила його. Та сама поведінка. Потім звинуватили PSU. Потім ядро, бо так роблять, коли втомлені.

Зрештою хтось помітив, що турбо-поведінка оновленого CPU інша: короткі спалахи пройшли нормально, а стійке навантаження викликало більший струм на всіх ядрах, ніж старий SKU коли-небудь просив. VRM радіатор на материнській платі був спроєктований під оригінальні валідовані SKU, а профіль повітряного потоку шасі був не надто добрий у кутку VRM. Під стійкими паралельними збірками температура VRM тихо зростала, поки не спрацював захист — миттєвий ресет.

Хибне припущення було в тому, що «той самий роз’єм означає ту саму потужність». Сумісність роз’єму — це вимога завантаження, а не операційна гарантія. Вони вирішили проблему, обмеживши ліміти потужності в BIOS до перевіреного контуру і посиливши криву обертів вентиляторів для цього пулу. Кінцеве виправлення — закупівля: припинити купувати найдешевший варіант плати для ролей з високим навантаженням CPU.

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

Інша команда керувала низьколатентними сервісами на bare metal. Після оновлення CPU вони помітили, що p99 латентність погіршилася під час сплесків трафіку. Завантаження CPU було в нормі. Load average не показував проблем. Першою думкою була «GC паузи» або «джиттер мережі». Почали налаштовувати потоки застосунку і пінувати ядра. Навіть розглядали переписати гарячий шлях, бо такий був тиждень.

Інженер з продуктивності помітив у моніторингу: частота коливалася під бурстовим навантаженням. Новий BIOS мав за замовчуванням увімкнений «enhanced turbo», що фактично прибрав розумні ліміти потужності. CPU агресивно підвищував частоту, швидко досягав теплових лімітів, потім тротлився. Результат був не в зниженні середньої продуктивності, а в її нестабільності. Латентність ненавидить нестабільність більше, ніж помірно нижчі частоти.

Вони «оптимізували», вмикаючи найагресивнішу політику boost, бо в бенчмарку це виглядало добре. У продакшені це створило пилообразний графік: boost, перегрів, тротлінг, відновлення, повтор. ОС планувальник зміщував роботу на «швидші» ядра, що змінило локальність кеша і ще більше погіршило хвостову латентність.

Виправлення було нудним: встановити явні PL1/PL2/Tau у стабільний профіль, який може витримати охолодження, і зафіксувати криву вентиляторів. Латентність одразу покращилась, і команда припинила сперечатися з реальністю. Вони віддали трохи пікового пропускного навантаження. Зате отримали передбачуваність — саме те, що помічають клієнти.

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

Команда зберігання даних планувала оновлення CPU для вузлів з інтенсивним шифруванням. Вони навчились через біль, що «маленькі зміни прошивки» не бувають маленькими. Тому вони поставили оновлення як зміну платформи: preflight, canary, rollout, postflight з чітким планом відкату.

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

Вони вибрали canary-хост, оновили BIOS до цільової бази, підтвердили завантаження мікрокоду в initramfs і запустили контрольований набір стрес-тестів, що включали AVX-навантаження і I/O-пресинг. Вони дивились на лічильники EDAC і логи PCIe AER, як на монітор серця. Хост пройшов, але лише після того, як вони знизили швидкість пам’яті на одну сходинку через нестабільність тренування з наявними DIMM.

Коли розгортання почалось, один вузол не пройшов POST після заміни CPU. Замість імпровізації вони виконали процедуру відкату: повернули старий CPU, завантажились, прошили BIOS знову, очистили NVRAM і повторили спробу. Працювало. Інцидент був локалізований, бо план передбачав дивні ситуації і дозволяв людям зупинитись і відкотитися.

У підсумку не було героїчного кейсу. Був тихий тиждень. Це правильний результат.

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

1) Симптом: випадкові перезавантаження лише під важкими обчисленнями

Корінна причина: Перегрів або захист від перенавантаження VRM, часто викликані стійким AVX або all-core boost.

Виправлення: Обмежте ліміти потужності в BIOS до того, що плата і охолодження можуть витримати; покращіть обдув VRM; уникайте налаштувань «multi-core enhancement/unlimited turbo» за замовчуванням.

2) Симптом: CPU «швидший» на папері, але пропускна здатність гірша

Корінна причина: Консервативні ліміти потужності (PL1 надто низький), тепловий тротлінг або пом’якшення, увімкнені новим мікрокодом/BIOS.

Виправлення: Виміряйте частоти під навантаженням; встановіть явні ліміти потужності; впевніться в охолодженні; порівняйте стани пом’якшень; прийміть усвідомлене рішення про безпеку/продуктивність.

3) Симптом: помилка POST після заміни CPU

Корінна причина: BIOS не підтримує CPU, або налаштування NVRAM несумісні з новим stepping, або регрес тренування пам’яті.

Виправлення: Оновіть BIOS, використовуючи відомий підтримуваний CPU спочатку; очистіть CMOS/NVRAM; тимчасово знизьте швидкість пам’яті і видаліть маргінальні DIMM, щоб завершити тренування.

4) Симптом: нові скориговані помилки пам’яті (ECC) після оновлення

Корінна причина: Різниці контролера пам’яті, змінені алгоритми тренування в новому BIOS, маргінальна цілісність сигналу DIMM або нестабільні умови VDD/Vcore.

Виправлення: Зменшіть швидкість пам’яті; переконайтесь, що DIMM відповідають правилам населення; оновіть BIOS; валідуйте тестами пам’яті; замініть підозрілі планки, якщо помилки йдуть за конкретним модулем.

5) Симптом: Live migration ламається після оновлення CPU

Корінна причина: Набір функцій CPU змінився; кластер більше не однорідний; гіпервізор відмовляє в міграції через невідповідність фіч.

Виправлення: Налаштуйте базові моделі CPU і маскування фіч; стандартизуйте мікрокод/BIOS по кластеру; перевірте шляхи міграції перед розгортанням.

6) Симптом: Переривчасті помилки пристроїв PCIe після оновлення

Корінна причина: Зміни в тренуванні PCIe, перемикання ASPM, зміна дефолтних налаштувань BIOS або чутливість прошивки кінцевого пристрою.

Виправлення: Перевірте логи AER; перепідключіть обладнання; встановіть відомі робочі налаштування PCIe в BIOS; оновіть прошивку кінцевих пристроїв; замініть riser/кабелі.

7) Симптом: Вентилятори голосніше, а тротлінг усе одно

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

Виправлення: Перемонтуйте радіатор, підтвердіть контакт; дотримуйтесь правильного моменту затягування; валідуйте потік повітря; встановіть стабільні ліміти потужності замість гонитви за піковим boost.

8) Симптом: У логах ядра зʼявилось «microcode updated» і несподівано змінилася продуктивність

Корінна причина: Ревізія мікрокоду відрізняється по хостах, або новий мікрокод змінив поведінку пом’якшень/еррат.

Виправлення: Стандартизуйте версії пакета мікрокоду; вбудовуйте в golden images; моніторте ревізію мікрокоду як елемент конфігурації; розгортайте як оновлення ядра.

Жарт №2: «Auto» в BIOS означає «автоматичні сюрпризи». Це прошивковий еквівалент дозволити малюку водити машину, бо він ентузіаст.

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

Передоновлювальний чекліст: вирішіть, чи варто взагалі оновлювати

1. Підтвердіть підтримку платформи: список підтримки CPU у вендора плати за точним SKU і stepping, а не лише за поколінням маркетингу.
2. Підтвердіть шлях прошивки: цільова версія BIOS, доступність відкату/пониження і метод прошивки (in-band vs out-of-band).
3. Підтвердіть подачу живлення та охолодження: придатність дизайну VRM, повітряний потік шасі, клас радіатора і запас потужності БП.
4. Підтвердіть правила населення пам’яті: ранг/розмір DIMM, швидкість і чи змінює CPU підтримувані режими пам’яті.
5. Підтвердіть характеристики робочого навантаження: інтенсивність AVX, стійке all-core навантаження, сплески чутливі до латентності або змішаний I/O + CPU.
6. Підтвердіть обмеження віртуалізації: базові моделі/masking CPU, сумісність міграції, ліцензійні привʼязки до моделі CPU, якщо є.

План вікна змін: виконуйте, очікуючи проблем

1. Інвентар та базова лінія: зафіксуйте поточні BIOS, мікрокод, ядро, стан пом’якшень і ключові метрики продуктивності.
2. Стандартизація прошивки спочатку: оновіть BIOS/UEFI до цільової версії на наявному CPU, якщо потрібно, підтвердіть завантаження і логи.
3. Canary — один хост: не оновлюйте пачками. Один хост, повний цикл валідації.
4. Встановіть CPU: дотримуйтесь ESD і крутного моменту. Пересуньте пам’ять, якщо торкалися. Не робіть «очистити і повторно використати пасту», як у 1999.
5. Перевірки після першого завантаження: підтвердіть ID CPU, ревізію мікрокоду, швидкість пам’яті і відсутність нових MCE/EDAC/AER помилок.
6. Контрольований стрес: запустіть CPU + пам’ять стрес і спостерігайте температури, частоти і логи в реальному часі.
7. Smoke тест робочого навантаження: запустіть репрезентативне навантаження або синтетичне, що відображає ваш вузький горловий елемент (crypto, compression, compile, JVM, БД).
8. Точка рішення про відкат: якщо бачите скориговані помилки, тротлінг або нестабільність — відкатуйте. Не домовляйтесь з попередженнями.

Післяоновлювальний чекліст: уникайте повільних інцидентів

1. Зафіксуйте конфігурацію: задокументуйте налаштування BIOS, що мають значення (ліміти потужності, C-states, SMT, профіль пам’яті, налаштування PCIe).
2. Моніторте потрібні лічильники: MCE/EDAC, PCIe AER, події тротлінгу, розподіл частот і температурні тренди.
3. Стандартизуйте доставку мікрокоду: упевніться, що пакети мікрокоду в initramfs однакові по флоту.
4. Перегляньте моделі ємності: оновіть базові лінії продуктивності та пороги запасу використовуючи спостережувану стійку продуктивність, а не пікові boost-значення.
5. Оновіть правила сумісності кластера: базові моделі CPU гіпервізора, маски фіч і політика міграції.

План відкату (напишіть його до того, як знадобиться)

• Тримайте принаймні один відомий робочий CPU на місці для шляхів відновлення BIOS.
• Підтримуйте образи прошивки BIOS для поточної і цільової версій, і знайте, в якому напрямку дозволено їхати.
• Зніміть конфігурацію BIOS (фото, експорт або текст) перед зміною.
• Визначте «умови зупинки»: будь-який новий MCE, зростання EDAC CE, тепловий тротлінг під стійким навантаженням або незрозумілі ресети.

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

1) Якщо роз’єм материнської плати підходить, чому я не можу припустити, що все працюватиме?

Бо фізична сумісність роз’єму — це лише фізична сумісність. Операційна сумісність вимагає підтримки прошивки, стабільного мікрокоду, правильної подачі живлення і валідованого тренування пам’яті для конкретного stepping CPU.

2) Чи оновлювати BIOS краще до чи після встановлення нового CPU?

Краще до, коли можливо. Оновіть BIOS на старому CPU, перевірте стабільність, потім міняйте CPU. Це зменшує кількість змінних і уникає пастки «не можу завантажитись, щоб прошити».

3) Чи достатньо мікрокоду, доставленого ОС, або потрібен ще й BIOS?

Часто потрібні обидва. Оновлення BIOS може містити код ініціалізації CPU, виправлення тренування пам’яті і платформні налаштування, які ОС замінити не може. Мікрокод від ОС сам по собі не вирішить усе, що контролює BIOS.

4) Чи можуть оновлення мікрокоду знизити продуктивність?

Так, залежно від пом’якшень і обходів еррат. Правильний підхід — виміряти і прийняти рішення усвідомлено, а не заперечувати можливість.

5) Як зрозуміти, що проблема в лімітах VRM?

Шукайте перезавантаження під стійким навантаженням, тепловий/потужнісний тротлінг і шаблон, коли короткі тести проходять, а довгі — падають. На деяких платформах можна спостерігати події тротлінгу і зіставляти їх з температурами та лімітами потужності.

6) Чому «auto» поведінка BIOS відрізняється між платами?

Бо вендори налаштовують «auto» під різні цілі: перемоги в бенчмарках, акустичні цілі, теплові зазори або консервативну корпоративну стабільність. «Auto» — це не стандарт; це характер прошивки.

7) Який найбезпечніший спосіб розгортання оновлень CPU у кластері?

Спочатку стандартизуйте прошивку, потім canary на одному хості, запустіть стрес і репрезентативні тести робочого навантаження, і лише потім розгортайте поступово, моніторячи апаратні лічильники і розподіли продуктивності.

8) Чи треба переживати про швидкість пам’яті після оновлення CPU?

Так. Контролер пам’яті CPU і код тренування BIOS взаємодіють. Новий stepping CPU або новий BIOS можуть змінити, що стабільно при певному населенні DIMM. Підтвердіть налаштовану швидкість і слідкуйте за EDAC.

9) Чи може оновлення CPU зламати live migration у віртуалізації?

Абсолютно. Нові функції CPU можуть з’явитись, і гіпервізори можуть відмовляти в міграції між різними наборами фіч. Використовуйте базові моделі/masking і тримайте кластери послідовними.

10) Коли варто припинити налагодження і просто відкотитися?

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

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

Оновлення CPU — це не «поменяв і поїхали». Ставтеся до них як до зміни платформи, тому що це так і є. Ось практичний шлях уперед:

1. Визначте цільовий результат: стійка продуктивність і стабільність важливіші за пікові boost-значення. Запишіть це в запиті на зміну.
2. Стандартизуйте прошивку і мікрокод: визначте базові версії і усуньте дрейф. Інвентаризація не є опційною.
3. Зробіть політику потужності явною: встановіть ліміти потужності і політику охолодження у відомий робочий конверт. Не дозволяйте «auto» визначати ваші SLO.
4. Використовуйте canary і умови зупинки: один хост ні про що не говорить; один хост, що впав, багато що повідомляє. Відкатуйте рано і без сорому.
5. Інструментуйте те, що має значення: MCE/EDAC/AER, події тротлінгу, розподіл частот під навантаженням і температури. Якщо ви цього не бачите, ви не можете цим керувати.

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

Брехня про сумісність: що мають на увазі постачальники проти того, що вам потрібно

Коли в оголошенні написано «сумісний з PCIe x16», зазвичай це означає «він використовує краєвий конектор PCIe у формі x16». Це як назвати паливний пістолет «сумісним», бо він підходить до носика.

Сумісність у виробництві — це тристоронній контракт:

• Механічна: чи вміщується він у корпус, чи не заважає фіксаторам і чи не давить сусідні слоти?
• Електроживлення: чи може БЖ та кабелі стабільно забезпечити живлення під час транзієнтів, а не лише середні ватти?
• Цілісність лінку: чи узгоджує PCIe-шлях очікувану швидкість і ширину, і чи залишається без помилок під навантаженням і при нагріванні?

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

Як виглядає «працює» vs як виглядає «працює надійно»

GPU, який «працює», буде:

• Зʼявлятися в lspci
• Пройти короткий бенчмарк
• Щось відрендерити протягом хвилини

GPU, який працює надійно, буде:

• Тримати свій PCIe-лінк на очікуваному поколінні і ширині протягом годин
• Не засмічуватися виправленими помилками PCIe під навантаженням
• Не стикатися з обмеженням потужності або провалами напруги при зміні навантаження
• Вижити після «теплого» ребута і не зникати
• Відновлюватися після скидання драйвера, не забираючи з собою хост

Одна цитата, яка варта уваги, коли хочеться довіряти специфікації:

«Надія — це не стратегія.» — перефразована ідея, яку приписують багатьом операційним лідерам

У світі GPU надія — це «воно один раз запостило». Стратегія — це «я можу пояснити, виміряти й обмежити режими відмов».

Реалії живлення GPU: роз’єми, рейли та транзієнтні стрибки

Сучасні GPU не просто споживають енергію; вони її різко втягують. Середнє число на коробці — ввічлива вигадка. Важливе поєднання таких чинників:

• постійне споживання під вашим навантаженням
• транзієнтні стрибки (мілісекунди)
• як ваш БЖ обробляє ці стрибки
• як ваші кабелі й роз’єми поводяться при великому струмі

Живлення з PCIe-слота — не ваш план B

PCIe-слот дає живлення (номінально до 75W у класичних десктопних очікуваннях). Серверні плати по-різному реагують на це, і багатографічні платформи часто розподіляють додаткове живлення через допоміжний кабель. Слот — для сигналізації й базового бюджету потужності. Схильність вважати його «резервом» призводить до потемнілих контактів і переривчастих збоїв, які відтворюються лише коли в приміщенні тепло.

8-pin, 6-pin і 12VHPWR: розʼєм — це не вся система

Розʼєми легко порахувати й важко зрозуміти. Безпечна доставлена потужність залежить від:

• товщини проводу (18 AWG vs 16 AWG має значення)
• якості розʼєму та глибини вставлення
• як багато конекторів ділять один кабель PSU (daisy chains)
• температури та потоку повітря навколо розʼєму
• контактного опору через знос і варіації виробництва

Екосистема 12VHPWR (16-pin) додала нові режими відмов: суворіші обмеження радіусу вигину, сигнальні піни та розʼєм, який карає часткову вставку. Якщо вам не пощастить, він карає вас теплом.

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

Single-rail vs multi-rail — це не релігія, але має значення

Multi-rail БЖ можуть спрацьовувати захист від перенавантаження, коли один GPU (або два GPU на одному шнурі) тягнуть великий транзієнт. Single-rail БЖ можуть охоче віддати пік — поки не зможуть, і зазвичай відмови такі драматичні.

В серверному контексті потрібно: передбачувана поведінка під транзієнтами, достатній запас потужності та кабелі, що не перетворюються на тостер. Так, я описую «нудне». Нудне — добре. Нудне — це аптайм.

Два практичні правила живлення, що рятують від самосаботажу

1. Ніякого «daisy-chaining» кабелів живлення GPU для високопотужних карт. Один кабель на конектор, якщо тільки виробник БЖ явно не сертифікував шнур для такого навантаження і ви не довели це в своїх умовах.
2. Бюджет на транзієнти. Якщо система «ледве» вкладається в потужність БЖ по паперах — вона вже не в специфікації в реальності.

Жарт №1: «Y-спліттер» — це як груповий чат — технічно всі підключені, але ніхто не отримує те, що йому потрібно.

Шини PCIe: податок пропускної здатності, який ви не помітили

PCIe продається як автострада. Насправді це більше схоже на автостраду з пунктами оплати, погодою і фазою переговорів, де GPU і материнська плата вирішують, на чому погоджуються, не пояснюючи вам чому.

Ширина і покоління: x16 не завжди x16

Той довгий x16 слот може бути:

• проведений як x16
• проведений як x8
• проведений як x4 (так, справді)
• ділити лінії з M.2 слотом або вбудованим NIC

Потім є покоління лінку. GPU, сертифікований для PCIe Gen4, може узгодитися вниз до Gen3, якщо ваш райзер хиткий, плата стара або цілісність сигналу на межі. Багато систем все одно «працюватимуть». Просто повільніше, іноді значно повільніше для навантажень з великим обміном даних.

Ділення ліній і біфуркація: дрібний шрифт, куди йде продуктивність

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

Біфуркація (розщеплення x16 на x8/x8 або x8/x4/x4) не включається автоматично, не завжди підтримується і не завжди стабільна з дешевими райзерами. У багатокартових конфігураціях налаштування біфуркації може вирішити, чи буде ваша друга карта працювати на x8 або взагалі не буде перелічуватись.

Помилки PCIe: виправлені помилки все одно вам коштують

Виправлені помилки PCIe — це «індикатор помилки двигуна» продуктивності GPU. Система продовжує працювати, але ви платите затримкою і пропускною спроможністю. Надто багато виправлених помилок — і ви отримаєте невиправлені помилки, скиди пристрою або GPU, що зникає під час завдання.

Якщо ваше навантаження чутливе (розподілене навчання, inference з низькою затримкою, GPUDirect Storage), різниця між чистим лінком і шумним лінком не делікатна. Це як день і ніч. І воно виглядає як «регресія програмного забезпечення», поки ви не перевірите лічильники.

Підводні камені сигналу: райзери, ретаймери, біфуркація та «працює на моєму стенді»

Кожен додатковий сантиметр PCIe-шляху — це місце, де електрони починають нервуватися. Додайте райзер, ретаймер, бекплейн, прокладіть поруч шумний VRM — і раптом Gen4 стає Gen3, а Gen3 — «чому карта смикається».

Райзер-кабелі: тихе пониження

Райзери бувають або інженерно зроблені, або надіяні. Якщо ви працюєте на швидкостях PCIe Gen4/Gen5, райзер — це компонент першого класу. Ставтесь до нього відповідно: кваліфікований, документований, стабільний. Дешевий райзер може узгодитися в Gen4 на холостому ходу і почати кидати помилки, коли GPU нагрівається і діаграма ока колапсує.

Ретаймери і редрайвери: не опція для вищих поколінь

На Gen4 і Gen5 багато дизайнів плат потребують ретаймерів, щоб тримати цілісність сигналу. Ретаймери можуть виправити маргінальні лінки, але вони також додають власний firmware, особливості й іноді суміснісні перепони. Якщо постачальник платформи каже «використовуйте ретаймер X з GPU Y», це не порада. Це визнання того, що фізика керує.

Налаштування BIOS: прихована рука

Якщо ви дебагуєте загадкове пониження, часто закінчуєте в BIOS:

• PCIe покоління примусово або авто
• Above 4G decoding (для великого BAR / багатьох пристроїв)
• Resizable BAR / Smart Access Memory (варіюється залежно від платформи)
• ASPM налаштування (збереження енергії, що може додати затримку і дивні ефекти)
• Режими біфуркації

Auto не завжди розумний. Auto — це «найкраща спроба з максимальною сумісністю». Для виробництва потрібні «відомі, фіксовані, валідовані» налаштування.

Жарт №2: PCIe «Auto» — як автодетектор дієти — технічно працює, поки ви не помітите, що вечеряєте пропускною здатністю.

Цікаві факти та коротка історія (щоб ви перестали повторювати старі помилки)

• Факт 1: PCI Express замінив AGP у середині 2000-х, і індустрія досі робить вигляд, що «x16 слот» означає «x16 електрично». Це не так.
• Факт 2: Класичні 6-pin і 8-pin PCIe-роз’єми стали поширеними, коли GPU виросли з того, що міг дати слот, перемістивши подачу живлення в окремі кабелі.
• Факт 3: Навчання PCIe-лінку (узгодження швидкості і ширини) — це динамічний процес; лінк може «провчитися» вниз, коли цілісність сигналу маргінальна, особливо з райзерами і бекплейнами.
• Факт 4: Виправлені помилки PCIe (AER) можна порахувати і залогувати; вони часто є найранішим вимірюваним сигналом про відмову райзера або маргінальної лінії.
• Факт 5: «TDP» — це точка теплового проєктування, а не сувора межа миттєвого споживання; транзієнтні стрибки можуть перевищувати TDP під поведінкою boost.
• Факт 6: Сучасні GPU реалізують агресивні алгоритми boost, що швидко змінюють напругу/частоту; це добре для бенчмарків і суворе до недостатньо підготовлених шляхів живлення.
• Факт 7: Розгортання серверних GPU пришвидшилось, коли deep learning перемістив GPU з «графіки» в «обчислення», зробивши стабільність PCIe першочерговою операційною проблемою.
• Факт 8: Функції Large BAR / Resizable BAR можуть покращити продуктивність в деяких навантаженнях, але також збільшують вимоги адресного простору і чутливість BIOS, особливо в мульти-пристроях.

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

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

Завдання 1: Підтвердити, що GPU перелічено та знайти адресу PCIe

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

Що це означає: GPU присутній на 03:00.0. Якщо він відсутній — ви в зоні BIOS/живлення/фізичної перевірки, а не драйвера.

Рішення: Якщо відсутній, зупиніться і перевірте посадку, роз’єми живлення, увімкнення пристроїв у BIOS і «Above 4G decoding», якщо у вас багато PCIe-пристроїв.

Завдання 2: Перевірити узгоджений стан PCIe-лінку за шириною і швидкістю

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

Що це означає: Пристрій може працювати в Gen4 x16, але навчене зниження до Gen3 x8. Це реальна втрата продуктивності для навантажень з великим обміном даних.

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

Завдання 3: Шукати помилки AER PCIe в логах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'AER|pcieport|Corrected error|Uncorrected'
[Mon Feb  3 12:44:51 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:03:00.0
[Mon Feb  3 12:44:51 2026] pcieport 0000:00:01.0: AER:   [ 0] RxErr

Що це означає: Лінк шумить. Виправлений RxErr часто вказує на цілісність сигналу: райзер, слот, ретаймер або маргінальне покоління.

Рішення: Якщо помилки корелюють з навантаженням/температурою — примусово знизьте покоління PCIe як тест. Замініть райзери/кабелі. Перемістіть GPU в перевірений робочий слот.

Завдання 4: Перевірити стан здоровʼя GPU, частоти і обмеження потужності (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d POWER,CLOCK,PERFORMANCE | sed -n '1,120p'
Power Readings
    Power Management            : Supported
    Power Draw                  : 286.45 W
    Power Limit                 : 320.00 W
    Default Power Limit         : 320.00 W
Clocks
    Graphics                    : 1845 MHz
    SM                          : 1845 MHz
Performance State              : P2

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

Рішення: Якщо ліміт потужності низький для карти, перевірте persistence mode і налаштовані обмеження. Якщо споживання нестабільне або GPU скидає P-стани під навантаженням, інспектуйте кабелі і запас по БЖ.

Завдання 5: Виявити причини тротлінгу по потужності/теплу (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i 'Clocks Throttle Reasons|Power Limit|Thermal|Reliability'
Clocks Throttle Reasons
    Idle                        : Not Active
    Applications Clocks Setting  : Not Active
    SW Power Cap                : Active
    HW Thermal Slowdown         : Not Active
    HW Power Brake Slowdown     : Not Active

Що це означає: Активний софтверний обмежувач потужності. Це налаштування, а не фізика. Хтось (або оркестраційний шар) обмежив карту.

Рішення: Перевірте налаштування nvidia-smi -pl, політики DCGM або обмеження контейнерного рантайму. Приберіть обмеження, якщо потрібна продуктивність, або прийміть їх, якщо потрібна стабільність живлення.

Завдання 6: Підтвердити реальність розʼємів/кабелів через телеметрію PSU (де доступно)

cr0x@server:~$ sudo ipmitool sdr type "Power Supply" | sed -n '1,80p'
PS1 Input Power     | 460 Watts        | ok
PS2 Input Power     | 455 Watts        | ok

Що це означає: Маєте базову інформацію про вхідну потужність БЖ. Вона не показує транзієнти GPU безпосередньо, але ви можете корелювати фази навантаження з поведінкою PSU.

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

Завдання 7: Підтвердити CPU-сторону топології PCIe (знайти ділення ліній)

cr0x@server:~$ lspci -tv
-+-[0000:00]-+-00.0  Intel Corporation Device
 |           +-01.0-[01-3f]----00.0  PCI bridge
 |           |               \-00.0  Non-Volatile memory controller
 |           +-03.0-[03]----00.0  VGA compatible controller

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

Рішення: Для інтенсивного трафіку GPUNVMe віддавайте перевагу платформам, де GPU і сховище мають достатньо незалежних ліній, або використовуйте розміщення, усвідомлене NUMA.

Завдання 8: Підтвердити NUMA-локальність (GPU поруч з яким сокетом CPU)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    CPU Affinity
GPU0     X      0-31

Що це означає: CPU-афініті вказує, які ядра «найближчі» до GPU. Неправильна локальність може виглядати як проблема PCIe, коли насправді це перетин сокетів.

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

Завдання 9: Перевірити стан Resizable BAR / large BAR (швидкий індикатор)

cr0x@server:~$ sudo lspci -s 03:00.0 -vv | egrep -i 'Resizable BAR|BAR 0|BAR 1' | head
Region 0: Memory at 3a00000000 (64-bit, prefetchable) [size=256M]
Resizable BAR: Disabled

Що це означає: Resizable BAR вимкнено. Іноді це нормально; іноді це дає помітний приріст. Іноді його ввімкнення ламає мульти-пристроєву ініціалізацію на старих BIOS.

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

Завдання 10: Валідувати налаштування MaxPayload/MaxReadReq (тонке налаштування, але також діагностика)

cr0x@server:~$ sudo lspci -s 03:00.0 -vv | egrep -i 'MaxPayload|MaxReadReq'
MaxPayload 256 bytes, MaxReadReq 512 bytes

Що це означає: Ці значення впливають на ефективність транзакцій. Вони також можуть вказувати на дивні платформні дефолти або обмеження від проміжних пристроїв (мости/ретаймери).

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

Завдання 11: Стрес-тест PCIe-шляху і спостереження за перевчанням лінку

cr0x@server:~$ sudo timeout 60s dmesg -wH
[Feb03 13:10:12] pcieport 0000:00:01.0: AER: Corrected error received: 0000:03:00.0
[Feb03 13:10:45] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Що це означає: Помилки зʼявляються під тривалим активним навантаженням. Виправлені помилки фізичного шару під стресом часто означають тонкий запас сигналу.

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

Завдання 12: Перевірити скиди GPU і події Xid (NVIDIA)

cr0x@server:~$ sudo dmesg -T | egrep -i 'NVRM: Xid|GPU has fallen off the bus|rm_init_adapter'
[Mon Feb  3 13:22:01 2026] NVRM: Xid (PCI:0000:03:00): 79, GPU has fallen off the bus.

Що це означає: GPU зник з PCIe. Це не обовʼязково «помилка CUDA». Зазвичай це нестабільність живлення, проблеми з цілісністю лінку або реально помираюча карта.

Рішення: Спочатку перевірте кабелі і запас БЖ, потім AER. Поміняйте GPU між нодами/слотами; поміняйте кабелі; усуньте адаптери. Якщо відтворюється на кількох нодах — робіть RMA карти.

Завдання 13: Перевірити, що масштабування частоти CPU не ваш фейковий вузький елемент

cr0x@server:~$ lscpu | egrep -i 'Model name|Socket|Thread|CPU\(s\)'
CPU(s):                          64
Socket(s):                       2
Model name:                      AMD EPYC 7xx2

Що це означає: Ви знаєте, на чому працюєте. Пропускна здатність GPU може бути обмежена CPU, який завантажений, повільний або виконує копіювання памʼяті через сокети.

Рішення: Якщо використання GPU низьке, а CPU завантажений — виправте конвеєр подачі: pinned memory, розміри батчів, NUMA-пінінг і розміщення сховища/NIC.

Завдання 14: Контроль шляху зберігання, якщо задачі GPU обмежені I/O (так, це постійно трапляється)

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    6.44    8.55    0.00   62.91

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await  %util
nvme0n1         220.0  45000.0     0.0    0.00   12.40   204.5     10.0    800.0    2.10   92.00

Що це означає: Високе завантаження NVMe і час очікування можуть відбирати ресурси у GPU. «GPU повільний» може означати «диск виснажився».

Рішення: Оптимізуйте підготовку даних, збільшіть паралелізм, використовуйте локальні NVMe-кеші або масштабуйтесь горизонтально. Не купуйте ще один GPU, щоб вирішити дискову проблему.

План швидкої діагностики: знайдіть вузьке місце перед тим, як здогадуватись

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

Перше: чи насправді GPU на чистому PCIe-лінку?

1. Перевірте перелічення: lspci -nn
2. Перевірте стан узгодження лінку: lspci -vv на LnkSta
3. Перевірте помилки AER: dmesg на виправлені/невиправлені помилки PCIe

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

Друге: обмеження по потужності чи теплове обмеження?

1. nvidia-smi -q -d POWER,PERFORMANCE
2. Шукайте причини тротлінгу: SW power cap, thermal slowdown, power brake
3. Корелюйте з повітряним потоком шасі і станом конекторів

Якщо активний power cap: вирішіть, чи це політика, чи неправильне налаштування. Якщо спрацьовує hardware power brake — підозрюйте БЖ/кабелі.

Третє: чи вузьке місце взагалі не там?

1. NUMA і топологія: nvidia-smi topo -m, lspci -tv
2. Конвеєр CPU: top, perf (якщо сміливі), потоки завантажувачів даних
3. Сховище/NIC: iostat, sar

Якщо використання GPU низьке: часто це I/O, CPU або міжсокетні копії памʼяті. GPU не врятують погану інфраструктуру.

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

1) Симптом: бенчмарки GPU в порядку, а продукційна задача повільна

Корінна причина: PCIe-лінк навчився вниз (Gen4→Gen3, x16→x8) або AER виправлені помилки під тривалим навантаженням.

Виправлення: Перевірте LnkSta і AER. Замініть райзер/бекплейн, перемістіть у інший слот, примусово зменшіть покоління PCIe в BIOS як тест. Підтвердіть стабільність на цільовому поколінні.

2) Симптом: «GPU has fallen off the bus» / Xid 79

Корінна причина: Нестабільність подачі живлення (транзієнти, поганий адаптер, неплотний 12VHPWR) або серйозний збій сигналу PCIe.

Виправлення: Пересадіть конектори, усуньте адаптери, використайте окремі кабелі від PSU, збільште запас потужності БЖ. Перевірте AER логи. Поміняйте GPU/кабелі між нодами для ізоляції.

3) Симптом: друга GPU не виявляється при встановленому NVMe

Корінна причина: Ділення ліній на материнській платі; M.2 забирає лінії із другого слота або примушує біфуркацію.

Виправлення: Читайте карту ліній плати. Перемістіть NVMe в інший слот/кореневий порт, змініть налаштування біфуркації або використайте платформу з достатнім числом ліній.

4) Симптом: випадкові перезавантаження під навантаженням

Корінна причина: Спрацьовування OCP/OPP БЖ через транзієнтні сплески, особливо з multi-rail БЖ або перевантаженими шнурами.

Виправлення: Збільшіть потужність БЖ, розподіліть GPU між БЖ, якщо підтримується, зменшіть ліміт потужності GPU і припиніть ділити кабелі живлення.

5) Симптом: GPU сильно гріється і тротлиться, незважаючи на «достатній повітряний потік»

Корінна причина: Патерн повітряного потоку шасі не відповідає дизайну охолодження GPU (open-air vs blower), або сусідні карти рециркулюють тепло.

Виправлення: Використовуйте серверні GPU/кулерні рішення, дотримуйтеся проміжку між слотами, перевірте криві вентиляторів і виміряйте температуру на впуску та випуску.

6) Симптом: Стабільно на Gen3, нестабільно на Gen4

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

Виправлення: Замініть райзер, додайте/оновіть ретаймерний шлях якщо застосовно, скоротіть шлях, або прийміть Gen3 як стабільну робочу точку.

7) Симптом: використання GPU сильно коливається; CPU завантажений

Корінна причина: Вузьке місце у конвеєрі даних (попередня обробка на CPU, малі батчі, свопінг, непінована памʼять).

Виправлення: Збільшіть batch size, використовуйте pinned memory де доречно, виведіть передобробку з критичних ядер і закріпіть потоки до локального NUMA.

8) Симптом: «Сумісні» кабелі БЖ не зовсім підходять

Корінна причина: Модульні кабелі БЖ мають різні розводки в залежності від вендора і навіть моделі; «підходить» не означає «те саме підключення».

Виправлення: Використовуйте тільки оригінальні кабелі PSU або схвалені замінники для точної моделі. Якщо ви перемішали кабелі — припиніть це і поверніть назад.

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

Чек-лист перед купівлею (що перевірити до прибуття GPU)

1. Пасування в корпус: довжина, висота, товщина, напрямок потоку повітря, відстань між слотами.
2. Бюджет ліній платформи: лінії CPU PCIe, проводка слотів (x16 vs x8), ділення ліній з M.2/U.2 та обмеження аплінку.
3. Бюджет живлення: ємність PSU з 30–40% запасом для багатокартових нод; підтвердіть ліміти по рейлам, якщо multi-rail.
4. План кабелювання: окремі кабелі на кожен конектор; уникайте спліттерів і невідомих адаптерів.
5. Термальний план: температура впуску в шафі, криві вентиляторів і чи підходить кулер GPU для корпусу.
6. План прошивок: версія BIOS, прошивка ретаймерів/бекплейну (якщо застосовно) і шлях відкату.

Чек-лист інсталяції (що робити руками)

1. Вимкніть живлення, відключіть кабелі, розрядьте напругу. Не ризикуйте гарячою заміною.
2. Щільно вставте GPU; перевірте вирівнювання фіксатора (без крутного моменту на слот).
3. Підключіть живлення: один шнур на конектор; перевірте повну вставку (особливо 12VHPWR).
4. Маршрутуйте кабелі з безпечним радіусом вигину; уникайте бічного навантаження на розʼєми.
5. Переконайтесь, що вентилятори вільно обертаються і нічого не торкається лопатей (таке трапляється).
6. Документуйте: слот, кабелі, порт PSU і будь-які адаптери (ідеально — їх нема).

Чек-лист валідації (що довести перед введенням в продакшн)

1. Перелік: lspci показує GPU.
2. Стан лінку: LnkSta відповідає очікуваному поколінню/ширині.
3. Без помилок: відсутній AER-спам під час стрес-тесту.
4. Поводження живлення: немає несподіваних обмежень потужності; немає подій power brake.
5. Терміка: стабільні температури під тривалим навантаженням; немає теплового тротлінгу.
6. Теплий ребут: GPU перелічується після ребута, не лише після холодного старту.

Контроль змін (нудна частина, що зберігає ваші вихідні)

1. Міняйте одну змінну за раз: кабель, слот, райзер, налаштування BIOS.
2. Логуйте до/після: ширина/швидкість лінку, підрахунок AER, споживання GPU, пропускна спроможність задачі.
3. Майте план відкату: профілі BIOS, запасні райзери, запасні відомо-гарні кабелі.

Три корпоративні історії з GPU-траншей

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

Вони розгорнули партію нових GPU у наявний обчислювальний флот. У закупівлі було «PCIe x16 compatible», що всі читали як «повна пропускна здатність». Встановлення пройшло чисто. Ноди завантажились. Планувальник задач почав підгодовувати їх роботою.

За день команди почали повідомляти, що навчальні задачі «нестабільні». Не падають — просто повільні. Деякі прогони були в порядку, інші ніби в меді. Перша реакція була передбачуваною: звинуватити новий драйвер, образ контейнера, версію фреймворку.

Зрештою хтось запустив lspci -vv і побачив: на половині нод тренувався Speed 8GT/s, Width x8. Не тому, що GPU відрізнялися — а тому, що материнські плати мали мікс ревізій проводки слотів у різних партіях закупівлі. Та сама модель шасі, різні спини плат. «Сумісний», так. Але не еквівалентний.

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

Що змінило рішення надалі — усвідомлення, що «x16 слот» — це форма, а не гарантія. Після того ніхто не відправляв ноду з GPU без фіксації топології і стану лінку в інвентарі.

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

Інша компанія хотіла зменшити кількість кабелів у багатокартових серверах. Ідея була розумною: менше шнурів PSU і якісні Y-кабелі. Кабельний порядок покращився, повітряний потік трохи кращий, а стійки виглядали як для каталогу.

Але потім почалися містичні перезавантаження. Не на всіх нодах. Не послідовно. Більше під час переходів фаз задач — коли GPU переходили з помірного споживання в повний буст. Іноді нода перезавантажувалась. Іноді одна карта зникала, а хост тупо працював з урізаним ресурсом.

Команда робила те, що роблять команди: шукала софтверних привидів. Крутили ядра. Оновлювали драйвери. Налаштовували живлення. Додавали ретраї в оркестрації. Кластер «стабілізувався» в сенсі, що відмови стали розпорошеніші і менш передбачувані.

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

Відкат був простим і дорогим у нудьзі: по одному кабелю на кожен розʼєм GPU, ніяких спліттерів, ніяких адаптерів. Аптайм покращився одразу. Кабельний безлад повернувся. Разом з ним — розум. «Оптимізація» перейменували в «зміни з тест-планом», що менш гучно, але точніше.

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

У третьому магазині вони ставилися до GPU-ноди як до масиву зберігання: стандартизовані частини, суворі BOM і приймальні тести. Це такий процес, на який всі скаржаться, поки щось не йде не так.

Постачання прийшло з правильною моделлю GPU, але з іншою партією збірок адаптерів 12VHPWR. Адаптери виглядали ідентично. Така сама упаковка, сімейство номерів деталей, інший виробничий прогін. Команда не повірила «виглядає ідентично». Вони запустили свій набір приймальних тестів.

Набір не був гламурним: перелік, підтвердження покоління/ширини лінку, тривалий стрес-тест, перевірка dmesg на AER і GPU Xid, перевірка стабільності споживання, теплий ребут, повторення. Дві ноди почали кидати виправлені помилки PCIe під тепловим навантаженням, а одна нода зареєструвала скидання GPU після теплого ребута.

Вони ізолювали партію, вставили відомо-гарні адаптери — і помилки зникли. Постачальник пізніше підтвердив проблему допуску в тій партії. Без впливу на продакшн, без дзвінка о півночі, без екстреного вікна змін.

Практика, що їх врятувала, не була геніальною. Це була відмова трактувати «сумісний» як тестовий результат. Вони тримали запасні відомо-гарні частини і вимірювали лінк. Нудьга перемогла.

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

1) Якщо мій GPU поміщається в x16 слот, отримаю я завжди x16 пропускної здатності?

Ні. Слот може бути механічно x16, але електрично провідний як x8/x4, або він може ділити лінії. Перевіряйте за допомогою lspci -vv (LnkSta).

2) Наскільки важлива різниця x16 vs x8 насправді?

Залежить від того, скільки трафіку хостGPU ви генеруєте. Чисті обчислювальні ядра з даними в памʼяті GPU можуть не помічати. Навантаження з великим обміном даних, велике inference та GPUDirect I/O часто дуже залежать від цього.

3) Чи варто примусово встановлювати PCIe Gen4/Gen5 у BIOS заради продуктивності?

Тільки після того, як доведете цілісність сигналу. Примусове підняття покоління на маргінальному шляху може перетворити «стабільно, але повільно» в «швидко, але нестабільно». Використовуйте примусове встановлення як тестовий інструмент, а не як дефолтний трюк.

4) Чи можна ігнорувати виправлені помилки PCIe?

Ігнорування їх — шлях до невиправлених помилок пізніше. Виправлені помилки — ранній сигнал тривоги; вони також тихо зʼїдають пропускну здатність. Трактуйте їх як дефект.

5) Чи є 12VHPWR за своєю суттю небезпечним?

Ні, не за своєю суттю, але він менш поблажливий. Часткова вставка, різкі вигини поруч із конектором і сумнівні адаптери можуть викликати перегрів. Робіть вставлення і маршрут кабелю частиною чек-листа установки.

6) Чи можна повторно використовувати модульні кабелі PSU з іншої моделі PSU?

Не робіть цього. Модульні конектори можуть бути фізично сумісні й електрично неправильні. Це найгірший тип «сумісності».

7) Чому GPU зникає після теплого ребута, але не після холодного старту?

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

8) У nvidia-smi GPU обмежений по потужності. Це завжди апаратна проблема?

Ні. Це може бути налаштований ліміт потужності (політика) або налаштування драйвера/менеджменту. Перевірте причини тротлінгу. Якщо спрацьовує hardware power brake — тоді підозрюйте БЖ/кабелювання.

9) Чи мають значення райзер-кабелі, якщо система «виявляє» GPU?

Так. Виявлення відбувається при низькому навантаженні. Помилки зʼявляються під нагрівом і тривалим трафіком. Райзер може пройти ініціалізацію і при цьому відмовити під реальним навантаженням.

10) Який найшвидший спосіб довести, що проблема апаратна, а не софтверна?

Перевірте LnkSta, перевірте помилки AER і перевірте події Xid. Якщо є пониження/помилки лінку або GPU зникає з шини — софт часто не є первинною причиною.

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

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

1. Зробіть стан лінку полем інвентаризації. Фіксуйте покоління/ширину PCIe по ноді і сигналізуйте при пониженнях.
2. Стандартизujte подачу живлення. Окремі кабелі на кожен конектор, жодних випадкових адаптерів і запас по БЖ, що враховує транзієнти.
3. Інструментуйте помилки. Підрахунки AER, події Xid і причини тротлінгу по потужності повинні бути видимими в логах і дашбордах.
4. Перевіряйте теплий ребут і тривале навантаження. Якщо працює лише холодний старт і холостий хід — це не працює.
5. Коли продуктивність погана, слідуйте за планом. Лінк → живлення/терміка → топологія/NUMA → сховище/CPU-конвеєр.

Зробіть це, і ви перестанете купувати апарат двічі: спочатку за гроші, а вдруге — за ваші вихідні.

Що мають на увазі під «багом скидання GPU»

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

• VFIO-прохід GPU (KVM/QEMU/libvirt), коли GPU прив’язують до VM, потім відв’язують і знову прив’язують.
• Контейнеризовані GPU-навантаження, коли драйвер хоста намагається відновитися після зависання ядра або некоректного DMA.
• Багатокористувацькі вузли з GPU з MIG/SR-IOV/vGPU, де семантика скидання відрізняється в залежності від режиму і прошивки.
• Шторми AER PCIe, фліпання лінку або GPU, що переходить у низькопотенційний стан і не повертається коректно.

Основна проблема проста: GPU — це не чемна мережева карта PCIe. Це складний SoC з кількома внутрішніми рушіями
(графіка, обчислення, копіювання, відео, дисплей), власною прошивкою і агресивним керуванням живленням. Коли ви «скидаєте PCIe-пристрій»,
ви не обов’язково скидаєте весь цей внутрішній стан — або робите це в неправильний момент, залишаючи пристрій
напівживим у стані, який плутає драйвер при наступній прив’язці.

Жарт №1: GPU не «падають», вони входять у стан роздумів, де переглядають свої стосунки з вашим драйвером.

Цікаві факти та історичний контекст (коротко, по суті)

1. PCIe FLR (Function Level Reset) з’явився, щоб стандартизувати скидання на рівні функції, але багато ранніх реалізацій були частковими або дивними.
2. Споживчі GPU оптимізувалися під один OS-інстанс на завантаження, задовго до того, як віртуалізація вимагала «постійного від’єднання/під’єднання».
3. Позначка AMD «reset bug» з’явилася у спільноті VFIO, тому що деяким моделям потрібне було повне скидання шини або цикл живлення для відновлення.
4. Процес збереження стану NVIDIA мав сенс для HPC-продуктивності, але ускладнює поведінку при «розриві і повторному зв’язуванні», коли ви очікуєте чистого скидання.
5. IOMMU спочатку створювався для трансляції DMA і захисту, а не як менеджер життєвого циклу пристрою.
6. Режими живлення PCIe як D3hot/D3cold можуть ламати повторну ініціалізацію, коли прошивка/BIOS і ОС не погоджуються, хто відповідає за пробудження.
7. ACS (Access Control Services) стали важливими, тому що споживчі платформи часто групують кілька пристроїв разом, блокуючи безпечний passthrough.
8. AER (Advanced Error Reporting) може бути порятунком для діагностики, але також може залити логи і погіршити стабільність вузла, коли пристрій некоректний.

Неприємний висновок: «скидання» — це не однорідне поняття. Це переговори між прошивкою платформи, топологією PCIe,
можливістю пристрою і поведінкою драйвера. І GPU — найпереговорливіші пристрої, які ви можете хостити.

Чому ізоляція IOMMU не гарантує відновлюваності

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

Але IOMMU не:

• гарантує, що пристрій можна повернути у чистий стан при відв’язуванні
• змушує пристрій коректно виконувати FLR
• скидає внутрішній стан прошивки, мікроконтролерів або лінії живлення
• виправляє зламану топологію PCIe, де GPU ділить домен скидання з іншими пристроями
• не захищає від очікувань постачальника драйвера щодо порядку ініціалізації

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

Два рівні ізоляції, які не слід плутати

Оператори плутають їх, бо вони виглядають поруч на діаграмах:

• Ізоляція DMA (IOMMU): «Чи може цей пристрій звертатися лише до дозволеної пам’яті?»
• Ізоляція життєвого циклу (reset domain): «Чи можна цей пристрій незалежно скинути і повторно ініціалізувати?»

Багато платформ дають вам перший, але тихо провалюються в другому. Ось де живе «IOMMU недостатньо».

Домени скидання: прихована залежність

GPU стоїть за root port, можливо за switch, іноді за PLX-чіпом, іноді ділить лінії з іншими пристроями.
Навіть якщо GPU у власній групі IOMMU, він може ділити лінію скидання або домен живлення з чимось іншим.
Коли ви робите bus reset, ви можете скинути сусідів. Коли ви робите FLR, GPU може його ігнорувати.
Коли ви нічого не робите, драйвер намагається «м’яко скинути» внутрішні рушії і іноді програє.

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

Цитата (парафразована ідея)

Парафразована ідея: надія — не стратегія — проектуйте системи так, щоб відмови були очікуваними, а відновлення — рутинним. — Джин Кранц (оперативний керівник, програма «Аполлон»)

Механізми скидання PCIe: FLR, bus reset, hot reset і чому GPU особливі

Function Level Reset (FLR)

FLR — це концептуально найчистіше: скинути лише одну PCIe-функцію (наприклад 0000:65:00.0), не ламаючи всю шину.
ОС може запитати це через sysfs, і VFIO використовує це, коли доступно.

Реальність: деякі GPU реалізують FLR так, що скидається конфігураційний простір, але не внутрішній стан прошивки, який вам справді важливий.
Або FLR працює лише коли пристрій у певному стані живлення. Або «працює», але рушії застрягають.

Bus reset / secondary bus reset

Це скидає сегмент шини, що нижчий по ієрархії. Більш жорсткий метод, ніж FLR. Більше побічних ефектів теж.
Якщо ваш GPU стоїть за PCIe-бріджем або switch’ом, bus reset іноді може змусити його поводитися правильно.

Підводний камінь очевидний: ви можете скинути інші кінцеві точки за тим же бриджем. Якщо вам пощастить, це нічого важливого.
Якщо ні — ви щойно перезавантажили свій HBA сховища посеред піку I/O. Удачі з поясненням такого графіка фінансу.

Hot reset

Hot reset ближчий до «імітації відключення/підключення на рівні лінку». Він може спрацювати, коли FLR не допомагає.
Він також може зазнати невдачі, якщо платформа не може коректно перевчити лінк або якщо прошивка пристрою застрягає під час тренування лінку.

Фундаментальне скидання / цикл живлення

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

• вузли з BMC-контрольованим живленням слотів PCIe (рідко, але золото)
• GPU-партіції, що переносять перезавантаження вузла
• підтримка перезапуску робочих навантажень і проєктування розкладу навколо відновлення

Чому GPU особливі (і дратівливі)

GPU містять кілька внутрішніх «субпристроїв» за однією PCIe-функцією: рушії копіювання, контролери пам’яті, відео-рушії,
дисплей-рушії, процесори безпеки і велику частину прошивки, яка ініціалізує все. Скидання, що не реініціалізує прошивку і стан контролера пам’яті, — це скидання лише за назвою.

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

Сумні сценарії відмов, які ви побачите в продакшні

1) «Скидання не вдалося» після вимкнення VM; наступне приєднання зависає

Класичний симптом VFIO: VM працює нормально. Ви її вимикаєте. Відв’язуєте GPU. Заново прив’язуєте до іншої VM. Libvirt каже, що все гаразд.
Гість завантажується до чорного консолі. Логи хоста показують невдале скидання, або драйвер відмовляється прив’язуватися.

2) GPU застряг у D3cold (або перемикається між станами живлення)

Пристрій присутній у lspci, але не ініціалізується. Іноді в логах ядра з’являється «не вдалося змінити стан живлення».
Часто це взаємодія з runtime power management: ядро намагається призупинити пристрій, потім ви намагаєтесь його скинути — і виходить безлад.

3) AER-спам, скидання лінку і «заморожені» вузли

GPU починає генерувати коректовані/нефатальні помилки PCIe. AER заливає dmesg. CPU витрачає час на обробку перервань.
Навіть якщо навантаження тривають, латентність вузла стає недовіреною.

4) Драйвер вважає GPU зайнятим вічно

Драйвер ядра намагається загасити пристрій, але внутрішні рушії застрягають. Він чекає сигналів з fence, які ніколи не приходять.
Ви намагаєтеся вивантажити модуль — і він блокується. Це не «аморальний баг драйвера»; драйвер робить єдину безпечну річ:
відмовляється вдавати, що апарат у порядку.

5) Сюрпризи мультифункцій: аудіо-функція, контролер USB-C тощо

Багато GPU експонують кілька функцій (графіка + HDMI audio + USB-контролер для VirtualLink/USB-C).
Скидання однієї функції без інших (або непослідовне прив’язування) може залишити пристрій у неконсистентному стані.

6) «Працює вранці» — збої пізніше

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

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

Це версія, яку ви запускаєте, коли дзвонить сторож і ви не хочете ставати PCIe-археологом.
Мета: визначити, чи у вас проблема з можливістю скидання, керуванням живлення,
прив’язкою драйвера або топологією/доменом скидання.

Перше: підтвердьте, що саме впало — скидання, прив’язка чи лінк

• Перевірте dmesg на наявність «скидання не вдалося», «AER», «link down», «device not ready».
• Перевірте в sysfs доступні методи скидання для PCIe-функції.
• Перевірте, чи пристрій у D3cold/D3hot.

Друге: валідуйте ризики топології і домену скидання

• Знайдіть upstream bridge/root port і подивіться, що ще за ним ділить шлях.
• Підтвердіть членство в IOMMU group, але на цьому не зупиняйтесь.
• Шукайте PCIe switch/bridge, який може бути реальним об’єктом скидання.

Третє: оберіть найменш руйнівну дію з відновлення

1. Спробуйте function reset (FLR), якщо доступно.
2. Спробуйте цикл unbind/bind (якщо драйвер підтримує чисту реініціалізацію).
3. Спробуйте hot reset або secondary bus reset, якщо GPU ізольований за власним bridge/switch.
4. Якщо помилки тривають або починаються шторми AER: злити вузол (drain), перезавантажити хост.

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

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

Усі приклади припускають хост Linux з root-доступом і GPU за адресою 0000:65:00.0.
Замініть адреси і назви драйверів відповідно.

Завдання 1: Ідентифікуйте GPU і його функції (чи бракує аудіо/USB-функції?)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd|audio|usb'
65:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2231] (rev a1)
65:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:1aef] (rev a1)

Що це означає: Ваш «GPU» — це принаймні дві функції. Плани passthrough/скидання мають враховувати обидві.
Рішення: Якщо ви пробросуєте 65:00.0, також подумайте про 65:00.1, щоб зберегти консистентність пристрою, або явним чином прив’яжіть її до безпечного драйвера.

Завдання 2: Перевірте, чи IOMMU справді ввімкнений (не припускайте)

cr0x@server:~$ dmesg | egrep -i 'iommu|dmarmr|intel-iommu|amd-vi' | head
[    0.912345] DMAR: IOMMU enabled
[    0.912678] DMAR: Host address width 46

Що це означає: Ядро вважає, що IOMMU увімкнений.
Рішення: Якщо ви цього не бачите, виправте параметри завантаження/BIOS; стабільність VFIO без IOMMU — фантазія.

Завдання 3: Перевірте членство в IOMMU group (необхідно, але не достатньо)

cr0x@server:~$ gpu=0000:65:00.0; group=$(readlink /sys/bus/pci/devices/$gpu/iommu_group); echo $group; ls -l $group/devices
../../kernel/iommu_groups/42
total 0
lrwxrwxrwx 1 root root 0 Feb  4 10:01 0000:65:00.0 -> ../../../../devices/pci0000:60/0000:60:01.0/0000:65:00.0
lrwxrwxrwx 1 root root 0 Feb  4 10:01 0000:65:00.1 -> ../../../../devices/pci0000:60/0000:60:01.0/0000:65:00.1

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

Завдання 4: Знайдіть upstream bridge/root port (підказка домену скидання)

cr0x@server:~$ gpu=0000:65:00.0; echo "GPU path:"; readlink -f /sys/bus/pci/devices/$gpu
GPU path:
/sys/devices/pci0000:60/0000:60:01.0/0000:65:00.0

Що це означає: Upstream порт — 0000:60:01.0.
Рішення: Перевірте, що ще знаходиться за 60:01.0. Якщо це спільний switch, bus reset може спричинити побічні ефекти.

Завдання 5: Перерахуйте все, що за тим же upstream портом

cr0x@server:~$ upstream=0000:60:01.0; find /sys/bus/pci/devices/$upstream/ -maxdepth 2 -name '0000:*' -printf '%f\n'
0000:65:00.0
0000:65:00.1

Що це означає: За цим портом знаходяться лише функції GPU.
Рішення: Bus reset на downstream-сегменті ймовірно безпечний (але все одно перевірте відсутність прихованого switch з іншими портами).

Завдання 6: Перевірте, чи ядро вважає FLR доступним

cr0x@server:~$ gpu=0000:65:00.0; lspci -s ${gpu#0000:} -vv | egrep -i 'Capabilities:.*FLR|Reset'
Capabilities: [1b0] Vendor Specific Information: Len=14

Що це означає: Цей вивід не доводить підтримку FLR; деякі пристрої не рекламують його чисто для grep.
Рішення: Користуйтеся sysfs далі; не покладайтеся на маркетингові списки можливостей.

Завдання 7: Спробуйте function reset через sysfs (найменш руйнівний)

cr0x@server:~$ gpu=0000:65:00.0; sudo sh -c "echo 1 > /sys/bus/pci/devices/$gpu/reset"
sh: 1: cannot create /sys/bus/pci/devices/0000:65:00.0/reset: Permission denied

Що це означає: Ви забули про root (або редирект shell не мав привілеїв).
Рішення: Використайте root shell або sudo tee для запису у sysfs.

cr0x@server:~$ gpu=0000:65:00.0; echo 1 | sudo tee /sys/bus/pci/devices/$gpu/reset
1

Що це означає: Ядро прийняло запит на скидання.
Рішення: Негайно перевірте dmesg на успіх/невдачу; прийняття не означає завершення.

Завдання 8: Підтвердьте результат скидання в dmesg (успіх vs «скидання не вдалося»)

cr0x@server:~$ dmesg -T | tail -n 20
[Sun Feb  4 10:05:01 2026] pci 0000:65:00.0: resetting
[Sun Feb  4 10:05:02 2026] pci 0000:65:00.0: reset failed

Що це означає: Платформа/пристрій не змогли завершити запитаний шлях скидання.
Рішення: Переходьте до hot reset / bus reset лише якщо GPU ізольований за власним bridge; інакше злити вузол і перезавантажити.

Завдання 9: Перевірте стан живлення (D0 vs D3), щоб виявити runtime PM пастки

cr0x@server:~$ gpu=0000:65:00.0; cat /sys/bus/pci/devices/$gpu/power_state
D3cold

Що це означає: Пристрій у глибокому вимкненні.
Рішення: Розгляньте відключення runtime PM для пристрою або забезпечте, щоб він був у D0 перед відв’язкою/скиданням.

Завдання 10: Тимчасово вимкніть runtime PM для GPU (тестова зміна)

cr0x@server:~$ gpu=0000:65:00.0; echo on | sudo tee /sys/bus/pci/devices/$gpu/power/control
on

Що це означає: Runtime PM примусово встановлено на «on» (без autosuspend) для цієї функції.
Рішення: Повторіть тести відв’язки/прив’язки. Якщо стабільність покращиться, зробіть це постійно через udev-правило або systemd unit (обережно).

Завдання 11: Відв’яжіть від поточного драйвера (підготовка до перев’язки або VFIO)

cr0x@server:~$ gpu=0000:65:00.0; readlink /sys/bus/pci/devices/$gpu/driver
../../../../bus/pci/drivers/nvidia

cr0x@server:~$ gpu=0000:65:00.0; echo $gpu | sudo tee /sys/bus/pci/drivers/nvidia/unbind
0000:65:00.0

Що це означає: Пристрій від’єднано від драйвера nvidia.
Рішення: Якщо unbind блокується або дає помилки, драйвер може очікувати на апарат; злити вузол і перезавантажити часто — єдиний чистий вихід.

Завдання 12: Прив’яжіть до vfio-pci (для passthrough) і перевірте прив’язку

cr0x@server:~$ gpu=0000:65:00.0; sudo modprobe vfio-pci

cr0x@server:~$ gpu=0000:65:00.0; vendor=$(cat /sys/bus/pci/devices/$gpu/vendor); device=$(cat /sys/bus/pci/devices/$gpu/device); echo $vendor $device
0x10de 0x2231

cr0x@server:~$ echo 10de 2231 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
10de 2231

cr0x@server:~$ gpu=0000:65:00.0; readlink /sys/bus/pci/devices/$gpu/driver
../../../../bus/pci/drivers/vfio-pci

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

Завдання 13: Перевірте на AER-помилки, що передбачають майбутні невдачі скидання

cr0x@server:~$ dmesg -T | egrep -i 'AER|pcieport|error' | tail -n 15
[Sun Feb  4 10:06:10 2026] pcieport 0000:60:01.0: AER: Corrected error received: 0000:60:01.0
[Sun Feb  4 10:06:10 2026] pcieport 0000:60:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

Що це означає: Існують проблеми на рівні лінку, навіть якщо GPU «працює».
Рішення: Трактуйте постійний AER як апаратну/платформну проблему: перевірте посадку, riser’и, кабелі (для зовнішнього PCIe), налаштування BIOS або замініть вузол.

Завдання 14: Перевірте швидкість/ширину лінку (деградовані лінки корелюють із дивними скиданнями)

cr0x@server:~$ gpu=0000:65:00.0; sudo lspci -s ${gpu#0000:} -vv | egrep -i 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Що це означає: Ваш GPU працює на деградованому лінку.
Рішення: Спочатку вирішіть фізичні/топологічні проблеми. Дебаг скидання на деградованому лінку — все одно, що дебаг сховища на помираючому SATA-кабелі: ви нічого корисного не дізнаєтесь.

Завдання 15: Спробуйте зробити downstream bus reset лише якщо топологія безпечна

cr0x@server:~$ upstream=0000:60:01.0; echo 1 | sudo tee /sys/bus/pci/devices/$upstream/reset
1

Що це означає: Ви запросили скидання upstream-порту/бріджа, що може скинути downstream-сегмент.
Рішення: Якщо інші пристрої ділять цей сегмент, не робіть цього на живому вузлі. Якщо GPU ізольований, це може відновити «завислий» пристрій.

Завдання 16: Перевірте, чи пристрій відгукується після скидання (швидкий індикатор здоров’я)

cr0x@server:~$ gpu=0000:65:00.0; lspci -s ${gpu#0000:} -nn
65:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2231] (rev a1)

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

Що працює: стратегії пом’якшення, що витримують реальні навантаження

1) Віддавайте перевагу GPU і платформам з перевіреною поведінкою скидання

Це не філософія. Це операційне питання. Якщо вам потрібні часті переназначення (multi-tenant VFIO, CI farm, епhemeral GPU VM),
ваше обладнання має підтримувати надійний FLR або передбачуваний bus reset без побічних ефектів.

Датацентр-клас GPU і сервери зазвичай поводяться краще, бо вони спроєктовані для флотських операцій і віддаленого відновлення.
Споживчі платформи можуть працювати, але ви підписуєтесь на хобі з параметрами ядра, ACPI-хаками і випадковими перезавантаженнями.

2) Тримайте GPU прив’язаним до одного світу якомога довше

Кожне відв’язування/прив’язування — шанс потрапити на поганий шлях. Якщо можна запланувати «GPU лишається з VM на весь її життєвий цикл», робіть так.
Якщо можна прив’язати GPU до вузла і переміщати роботи замість GPU — робіть це. Якщо можна уникати VFIO і використовувати контейнери на хості,
робіть це (за умови, що ви довіряєте моделі багатокористувацького доступу і маєте контролі ізоляції).

3) Вимкніть runtime PM для passthrough-GPU (селективно)

Runtime PM економить ватти. Він також вводить стани, що ускладнюють скидання/перев’язку. Для passthrough-GPU надійність важливіша за елегантність.
Примусово встановлюйте D0 під час переходів життєвого циклу або повністю вимикайте runtime PM для пристрою.

4) Трактуйте «скидання не вдалося» як проблему здоров’я вузла, а не випадковий глюк

Якщо GPU не вдається скинути один раз, ймовірність повторення зростає за схожих умов. Позначайте вузол як нездоровий, зливайте робочі навантаження
і перезавантажуйте за розкладом, а не в пік.

5) Використовуйте контрольовану «сходи скидання»

Не стрибайте відразу до bus reset. Використовуйте ескалацію:

1. Переконайтеся, що жоден процес не використовує GPU (або коректно зупиніть VM).
2. Відв’яжіть драйвер (хост) або від’єднайте пристрій (VFIO).
3. Спробуйте FLR через sysfs.
4. Спробуйте hot/bus reset лише якщо ізоляція підтверджена.
5. Якщо все ще зламано: перезавантажте вузол; якщо повторюється — змінюйте прошивку/платформу.

6) Узгодьте налаштування прошивки/BIOS з очікуваннями щодо скидання

BIOS/UEFI може підірвати вас налаштуваннями живлення і опціями PCIe. Типові покращення (залежить від платформи):

• Вимкніть глибокі PCIe-стани для слота, якщо бачите проблеми з D3cold.
• Увімкніть Above 4G Decoding для великих BAR-пристроїв і сучасних GPU.
• Оновлюйте VBIOS GPU і системний BIOS разом; невідповідні покоління створюють «працює, поки не перестане» поведінку.

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

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

Жарт №2: Найнадійніше скидання GPU — це те, яке виконує блок живлення, що коротко «забуває», що подавало живлення.

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

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

Середня SaaS-компанія побудувала сервіс інференсу на GPU. Вони хотіли жорстку ізоляцію орендарів, тож використали VFIO passthrough:
по одній VM на клієнтське навантаження, GPU переназначали під час життєвого циклу VM. Команда платформи ввімкнула IOMMU, перевірила IOMMU-групи і написала
автоматику, що від’єднувала і знову прив’язувала пристрої між VM.

Це пройшло стаджинг. Пройшло лоад-тести. Розгортання почалося тихо і виглядало нормально кілька днів — саме так платформа втрачала довіру перед катастрофою.

Перший інцидент почався як «деякі завдання зависають». Потім стало «половина GPU не розподіляється». VM були здорові.
Libvirt повідомляв успішне від’єднання/під’єднання. Але пристрої GPU не ініціалізувалися у наступній VM після від’єднання.
Оператори знайшли «скидання не вдалося» в dmesg і спостерігали, як unbind блокується. Кілька вузлів почали логувати коректовані PCIe-помилки,
що поступово перетворилося на шторми.

Хибне припущення було простим: «групи IOMMU означають безпечне повторне використання». Ізоляція була правильною. Відновлюваність — ні.
Моделі GPU у тому флоті можна було передавати, але їхня поведінка скидання була ненадійна при повторному навантаженні.
Вони не були зламані для десктопного використання; вони просто не створювалися для такого циклу життєвого циклу.

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

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

Фінансово-аналітична фірма виконувала важкі обчислення вночі. Вони хотіли зменшити витрати на електроенергію і ввімкнули агресивне
runtime power management. Ідея була розумною: GPU простоюють між сплесками, автопауза — економія ватів.

Через два тижні вони отримали новий клас відмов: вузли, які виглядали здоровими, але відмовлялися запускати GPU-завдання після простою.
Планувальник призначав задачу, задача не могла відкрити пристрій, повтори стрибали вузлами, і з часом кластер виглядав «завантаженим», але майже нічого не робив.
Класичний міраж завантаження.

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

Вони відключили runtime PM для функцій GPU, що використовуються для обчислень. Витрати на електроенергію трохи зросли. Продуктивність зросла більше.
Найважливіше — кластер перестав брехати про свою доступність.

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

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

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

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

Вони також мали суворий процес відновлення: вузол, що задокументував невдачу скидання, негайно зливався, перезавантажувався і повертався до сервісу лише після проходження стандартизованого циклу тестів attach/detach.
Ніякого геройського дебагу в робочий час.

Коли нова версія драйвера ввела більш часті крайові випадки скидання для однієї сімейства GPU, вплив був локалізований.
Планувальник уникав ризикових вузлів, цикл drain-and-reboot запобіг довгим AER-штормах, і користувачі здебільшого бачили перезапуск задачі, а не її зависання.
Це не було гламурно. Це було правильно.

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

1) Симптом: «скидання не вдалося» після відв’язки; GPU не переприв’язується

Причина: Пристрій не підтримує надійну FLR; шлях скидання драйвера неповний; GPU застряг у внутрішньому стані прошивки.
Виправлення: Уникайте частого відв’язування/прив’язування; прив’язуйте GPU на весь життєвий цикл VM; використовуйте bus reset лише з ізольованим downstream-портом; інакше перезавантажуйте вузол.

2) Симптом: GPU присутній у lspci, але прив’язка драйвера не вдається з таймаутами

Причина: GPU у D3cold або платформа не може його розбудити; конфлікт runtime PM.
Виправлення: Примусово встановіть /sys/bus/pci/devices/…/power/control в on; відрегулюйте налаштування BIOS PCIe живлення; забезпечте, щоб пристрій був у D0 перед повторною прив’язкою.

3) Симптом: Збільшення коректованих помилок AER; випадкові відмови задач

Причина: Проблеми цілісності сигналу/лінку, проблеми з riser, деградований лінк, маргінальний слот.
Виправлення: Пересадіть GPU, замініть riser/кабель, перевірте ширину/швидкість лінку, оновіть прошивку; карантинуйте вузол, якщо проблема постійна.

4) Симптом: Вивантаження драйвера GPU зависає назавжди

Причина: Драйвер чекає, поки апаратні рушії не спокійні; мікроконтролер GPU заклинив.
Виправлення: Не боріться з цим. Зливайте та перезавантажуйте. Потім розслідуйте, чому відбуваються заклинювання (терміка, прошивка, навантаження, розгін, живлення).

5) Симптом: VFIO працює лише один раз після завантаження

Причина: Скидання працює при холодному завантаженні, але не після використання гостем; відсутній вендорний quirk для скидання або потрібен bus reset/цикл живлення.
Виправлення: Перевірте можливість скидання перед розгортанням; плануйте перезавантаження хоста між призначеннями; віддавайте перевагу обладнанню з відомо доброю поведінкою скидання.

6) Симптом: Вимкнення VM спричиняє нестабільність хоста або скидання інших пристроїв

Причина: Ви застосували bus reset на бридж, спільному з іншими кінцевими точками (сховище, NIC).
Виправлення: Промапте топологію; ізолюйте GPU за виділеними root port; не робіть bus reset на спільних сегментах у продакшні.

7) Симптом: «Працювало в staging», але ламається при частому churn

Причина: Тести не покривали тривалого часу роботи, великого навантаження VRAM або повторних attach/detach циклів; стани прошивки залежать від навантаження.
Виправлення: Додайте soak-тести з attach/detach циклами; класифікуйте вузли за спостережуваною надійністю скидання; автоматизуйте ремедіацію.

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

Чек-лист A: Перед масштабним розгортанням VFIO GPU passthrough

1. Переконайтеся, що IOMMU увімкнено в BIOS і ядрі; підтвердіть повідомлення DMAR/AMD-Vi.
2. Підтвердіть функції GPU і переконайтеся, що всі враховані (графіка/аудіо/USB).
3. Змапте IOMMU-групи і топологію; ідентифікуйте upstream-порти і спільні сегменти.
4. Запустіть soak-тест циклу відв’язки/прив’язки (десятки до сотень циклів) під реальним навантаженням (навантаження VRAM + обчислення).
5. Визначте контракт відновлення: «відновлення без перезавантаження» або «перезавантаження прийнятне». Запишіть це у runbook.
6. Реалізуйте карантин вузла: якщо скидання не вдалося один раз — видаліть вузол із планування до ремедіації.

Чек-лист B: Безпечна «сходи» відновлення під час інциденту

1. Зупиніть або перемістіть навантаження; переконайтеся, що жоден процес не використовує GPU.
2. Зберіть докази: хвіст dmesg, lspci -vv стан лінку, стан живлення, поточна прив’язка драйвера.
3. Спробуйте FLR через sysfs reset на функції.
4. Якщо досі не працює і лише якщо топологія безпечна: скиньте upstream порт/брідж.
5. Якщо почався AER-шторм або повторні відмови: злити вузол, перезавантажити, відправити вузол на глибоке розслідування.

Чек-лист C: Зробіть це нудним (найнадійніший варіант)

1. Маркуйте вузли по сімейству GPU/прошивці та спостережуваній поведінці скидання.
2. Плануйте навантаження з великим churn лише на «хороші для скидання» вузли.
3. Вимикайте runtime PM для passthrough-GPU, якщо немає доказів безпечності.
4. Контролюйте версії ядра/драйверів/прошивки; впроваджуйте зміни через канарки і плани відкату.
5. Автоматизуйте цикл перезавантаження + тест здоров’я; ставте перезавантаження як інструмент обслуговування, а не ознаку слабкості.

FAQ

Q1: Якщо GPU у власній IOMMU-групі, чому його не завжди можна скинути?

Групування IOMMU стосується меж доступу DMA. Здатність до скидання залежить від підтримки PCIe-скидання, доменів живлення, стану прошивки
і топології. Вони пов’язані, але не тотожні.

Q2: Це лише проблема AMD?

Ні. У різних постачальників — різні закономірності, але відмови скидання трапляються в усіх сімействах GPU. Спільнота VFIO історично
підкреслювала випадки AMD «reset bug», але NVIDIA та інші також можуть клинити в залежності від моделі, прошивки та шляху драйвера.

Q3: SR-IOV або MIG усувають проблеми скидання?

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

Q4: Чи можна виправити це лише програмно через параметри ядра?

Іноді можна покращити поведінку (особливо навколо керування живленням або прив’язки драйвера), але не можна програмно вирішити проблему пристрою,
який потребує фундаментального апаратного скидання. Розглядайте вибір апаратури і топологію як пріоритетні.

Q5: Яке скидання найбезпечніше спробувати першим?

Function-level reset (FLR) через sysfs зазвичай найменш руйнівний. Якщо воно не допомагає, наступні кроки залежать від топології. Bus reset
може спрацювати, але несе побічні ризики.

Q6: Чому GPU іноді працює після перезавантаження хоста, але не після відв’язки/прив’язки VM?

Холодне завантаження встановлює чисту відправну точку: прошивка ініціалізується заново, лінії живлення перезапускаються, лінк коректно тренується.
Цикл відв’язки/прив’язки часто покладається на часткові скидання і шляхи teardown драйвера, які можуть не повністю реініціалізувати внутрішній стан GPU.

Q7: Чи варто вимикати AER, щоб припинити спам в логах?

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

Q8: Чи прийнятно планувати перезавантаження як метод відновлення?

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

Q9: Чому іноді відв’язка драйвера зависає?

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

Q10: Який єдиний найкращий метрик для алерту?

Сигналізуйте про невдачі скидання і повторювані події AER на root-портах GPU. Вони сильно корелюють з тим, що «цей вузол потім витратить ваш час».
Далі автоматизуйте карантин і ремедіацію.

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

Якщо запам’ятати одну річ: IOMMU дає безпеку DMA, а не безпеку скидання. Клас багів скидання GPU — це те, що відбувається, коли ми
плутаємо ці речі і будуємо автоматику, що припускає, ніби пристрої поводяться як безстанні периферійні пристрої.

Наступні кроки, які швидко приносять виграш:

1. Інвентаризація топології: змаркуйте upstream-порти, спільні бриджі і IOMMU-групи для кожного GPU-вузла.
2. Впровадьте сходи скидання: FLR → обережний bus reset (лише якщо ізольовано) → drain і reboot.
3. Вимкніть runtime PM для passthrough-GPU, якщо бачите дивні D3cold/D3hot стани.
4. Впровадьте карантин вузла: одна невдача скидання має видаляти вузол з планування до перезавантаження + тесту здоров’я.
5. Змініть критерії закупівлі: вимагайте перевіреної поведінки скидання, контроль живлення слота якщо можливо, і платформи, спроєктовані для віртуалізації.

Ось так ви перетворюєте «баг скидання GPU» з повторюваного інциденту на відому обмеження з нудною, надійною відповіддю.
Нудно — це добре. Нудно означає, що ви отримаєте свої вихідні дні назад.

Справжнє питання: чи може зовнішній пристрій стати майстром шини?

«Чи потрібен IOMMU на настільних ПК?» — це не те питання, з якого варто починати. Правильне питання:
Чи може те, що ви під’єднаєте, отримати доступ до пам’яті через DMA, прямо або через ланцюжок «допоміжних» контролерів?

Thunderbolt фактично — це зовнішній PCIe з гарним відділом маркетингу. Зовнішній PCIe означає зовнішні пристрої, які можуть робити те, що й внутрішні PCIe-карти:
запитувати читання/запис пам’яті через DMA. Якщо ви дозволяєте недовіреному пристрою робити DMA у вашу оперативну пам’ять, ваша ОС не має права голосу. Не ваш антивірус. Не екран входу в систему. Не повне шифрування диска після запуску машини.

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

Надійність також залежить від тієї самої межі. Пристрої, що поводяться некоректно і роблять «поганий» DMA (випадково, не навмисно), можуть пошкодити пам’ять, зависити інтерфейс вводу-виводу або спричинити критичні помилки PCIe, які виглядають як «випадкові» збої. У виробничому сенсі: це не випадково; це необмежено.

Що таке Thunderbolt насправді (і чому це нервує фахівців із безпеки)

Thunderbolt — це протокол тунелювання. Через один фізичний кабель він може передавати PCIe і DisplayPort, плюс USB та живлення в епоху «USB-C».
Важливою є частина PCIe. Якщо ви тунелюєте PCIe, ви тунелюєте й привілеї, що дає PCIe.

Сучасні контролери Thunderbolt і стек ОС намагаються зробити це безпечнішим. Існують рівні безпеки, авторизація пристроїв і підтримка перенесення DMA (DMA remapping).
Але це все ще система систем: політика BIOS/UEFI, мікропрограма контролера, налаштування ядра ОС і поведінка драйверів повинні узгодитися. Хоч щось із цього може непомітно послабити вашу позицію.

Практична інтерпретація:

• Якщо у вашому настільному ПК є Thunderbolt і ви підключаєте доки/eGPU/зберігання: слід розглядати IOMMU + налаштування безпеки Thunderbolt як обов’язкову гігієну, а не «лише для серверів».
• Якщо ви ніколи не використовуєте Thunderbolt або можете його вимкнути: відключення в прошивці часто є найчистішим способом зменшити ризик.
• Якщо у вашій моделі загроз важливий фізичний доступ недовірених осіб: вам потрібні обмеження Thunderbolt до завантаження та захист DMA на рівні ОС. Також варто подумати про стани сну (про це далі).

Жарт №1: Thunderbolt — це як дати ноутбуку бічні двері в PCIe-фабрику — бо що ж може піти не так із бічними дверима, які відкриваються кабелем?

IOMMU простими словами: що захищає, а що — ні

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

Що насправді дає IOMMU

• Ізоляція DMA: пристрій не може читати/записувати довільну RAM, якщо на це немає відображення.
• Утримання некоректних пристроїв: пристрій, що робить некоректний DMA, призведе до помилки замість безшумного пошкодження пам’яті.
• Основа для безпечного hotplug: Thunderbolt — це hotplug. Hotplug без обмеження DMA — фактично «підключай і молись».
• Віртуалізація і passthrough: якщо ви використовуєте KVM/QEMU, PCI passthrough, VFIO або сучасні контейнерні робочі процеси з GPU, вам вже потрібно правильно налаштований IOMMU.

Чого IOMMU не вирішує сам по собі

• DMA до завантаження на системах, які його дозволяють: якщо прошивка дозволяє пристрою робити DMA до того, як ОС налаштує перенесення, це вікно вразливості.
• Зловмисні пристрої всередині дозволених відображень: якщо ви авторизували Thunderbolt-пристрій і ОС відобразила йому широку область пам’яті, пристрій все ще може завдати шкоди в межах цього відображення.
• Погана політика прошивки: якщо налаштування BIOS/UEFI є занадто ліберальними, ви можете постраждати ще до того, як ОС отримає шанс.
• Всі проблеми надійності: обриви лінку, проблеми з живленням, погані кабелі, ретаймери та баги мікропрограми контролера не втримаються вашою IOMMU-філософією.

Є корисна ментальна модель: IOMMU необхідний, але недостатній.
Вам варто його увімкнути, бо це єдиний реальний апаратний механізм для обмеження DMA, але все одно потрібна політика: які пристрої довірені, коли і за яких умов.

Цитата, бо вона пасує тут: Сподіватися — це не стратегія. (парафраз ідеї, що часто звучить у інженерних/операційних колах)

Моделі загроз для настільних ПК, що справді мають значення

Більшість порад в Інтернеті для десктопів передбачає або (a) ви геймер з eGPU, або (b) ви користувач ноутбука, який хвилюється про атаку «зла господиня» (evil maid).
Виробничі настільні ПК розташовані посередині: вони іноді доступні фізично, і в них постійно зберігаються важливі облікові дані.

Модель загроз A: «Офісна реальність» фізичного доступу

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

Модель загроз B: доки та перехідники з елементами ланцюжка постачання

Док спочатку «лише док», поки він не надійде з прошивкою, яка робить щось несподіване, або поки дешевий перехідник насправді не виявиться маленьким комп’ютером.
Вам навіть не потрібно зловмисне наміри; неправильно реалізований пристрій все одно може зіпсувати вам день, посилаючи потоки PCIe-помилок.

Модель загроз C: надійність і цілісність даних

Інженерам зі зберігання даних важливі нудні режими відмов: корупція, скидання шин, kernel panic та мовчазне зниження швидкості до USB2 через поганий кабель.
Зовнішній PCIe швидкий — і крихкий. IOMMU може запобігти деяким категоріям корупції, але він також додає складності, яка може проявитися як «чому мій пристрій зникає тільки коли я вмикаю VT-d?»

Отже, чи потрібен IOMMU на настільних ПК?

Якщо у вашому настільному ПК є Thunderbolt і ви ним користуєтеся, увімкніть IOMMU. Якщо у вас є Thunderbolt і ви його не використовуєте, вимкніть Thunderbolt.
Якщо ви не можете його вимкнути, увімкніть IOMMU і встановіть сувору безпеку Thunderbolt.

Винятки вузькі: дуже старі системи з некоректними реалізаціями IOMMU або нішеві аудіо/відео конфігурації, де увімкнення IOMMU явно додає проблем з затримкою — рідко, але трапляється.
Навіть у таких випадках я віддав би перевагу виправити систему, а не працювати з прийнятим базовим рівнем «зовнішній PCIe може робити DMA у мою пам’ять».

Факти та історичний контекст, які варто знати

1. Thunderbolt починався як «Light Peak», спочатку уявлявся як оптичний інтерконект, поки мідь не перемогла в ціні та споживанні енергії.
2. Thunderbolt тунелює PCIe, тому eGPU та зовнішні NVMe-корпуси можуть відчуватися «внутрішньо-швидкими», коли все працює коректно.
3. Атаки через DMA виникли ще до Thunderbolt: FireWire (IEEE 1394) відкривав подібні проблеми, бо дозволяв схожі патерни доступу до пам’яті в деяких реалізаціях.
4. Дослідження «Thunderclap» (середина 2010-х) підкреслили реальні шляхи атак через DMA проти Thunderbolt на поширених ОС, що змусило виробників покращити захисти.
5. Існують рівні безпеки Thunderbolt (часто описуються як SL0–SL3), від «без безпеки» до режимів, що вимагають авторизації і обмежують поведінку до завантаження.
6. Kernel DMA Protection стала важливою функцією Windows у відповідь на ризики зовнішнього DMA; вона залежить від підтримки апаратури та прошивки.
7. Linux інтегрував авторизацію Thunderbolt через підсистему thunderbolt і sysfs-контролі; багато дистрибутивів тепер за замовчуванням використовують безпечніші режими «авторизації користувачем», якщо це підтримується.
8. USB4 успадковує багато моделі Thunderbolt; конектор може позначатися як USB-C, але безпека залежить від протоколів, узгоджених під час з’єднання.
9. Групи IOMMU відображають апаратну топологію, а не вподобання: деякі материнські плати об’єднують кілька пристроїв в одну групу, що обмежує ізоляцію і безпечний passthrough.

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

1) Інцидент через неправильне припущення: «Це ж просто док для монітора»

Середня інженерна організація розгорнула однакові док-станції Thunderbolt, щоб пришвидшити підключення на робочих місцях. Припущення на папері було слушним:
доки — це периферія, а периферія — невисокий ризик. Чек-лист розгортання зосереджувався на відображенні і стабільності Ethernet, а не на DMA.

Через кілька тижнів помітили дивну картину: розробники час від часу скаржилися, що запити облікових даних поводяться «неправильно», а кілька машин викидали журнали ядра,
заповнені PCIe AER помилками одразу перед крахом. Безпеку викликали лише після того, як під час судово-технічного аналізу виявили ознаки зчитування пам’яті.
Ніхто не міг довести зловмисність, але й ніхто не міг довести невинність — а це означає поганий день в операціях.

Корінь проблеми був у тому, що частина машин поставлялася з лояльними налаштуваннями Thunderbolt до завантаження, а IOMMU був вимкнений у BIOS на деяких настільних ПК
через старий внутрішній міф «VT-d знижує продуктивність». Сам док, ймовірно, не був зброєю; середовище було надто довірливим.
Коли ви даєте тунелюванню PCIe вільний хід, ви ставите на карту весь флот залежно від кожного оновлення прошивки дока.

Виправлення було не гламурним: стандартизувати налаштування BIOS (увімкнути VT-d/AMD-Vi, встановити безпеку Thunderbolt в режим авторизації, де можливо — відключити Thunderbolt до завантаження),
впровадити політики ОС і додати аудит подій підключення в моніторинг кінцевих точок. Доки не стали швидшими. Інциденти — припинилися.

2) Оптимізація, яка обернулася проти: «Вимкніть IOMMU заради нижчої затримки»

Команда постпродакшн відео мала справжню чутливість до затримки: аудіоінтерфейси, захоплення та відтворення в реальному часі. Один технічний блог запропонував
вимкнути IOMMU, щоб зменшити накладні витрати. Хтось спробував, швидкий тест пройшов, і ця зміна потрапила в їх «зелений образ».

Через кілька місяців почалися «незрозумілі» пошкодження файлів на зовнішньому високошвидкісному сховищі, підключеному через зовнішні NVMe-корпуси Thunderbolt.
Непослідовно. Неможливо відтворити на вимогу. Найгірший тип корупції: той, що виявляється після доставки, коли клієнт переглядає матеріал.
Усі звинувачували бренд накопичувача, постачальника кабелю і одного невдалого асистента монтажу.

Курящим доказом стало порівняння дампів і журналів ядра між машинами: корупції групувалися навколо подій hotplug PCIe і скидів лінку.
Без IOMMU одна проблемна ревізія прошивки корпусу могла DMA-нути в місця, де не слід, під час шляхів відновлення після помилок.
Це не була гарантована корупція; це була «можлива корупція». Саме так ви опиняєтеся на нарадах з юридичним відділом.

Повернення IOMMU не вирішило миттєво кожну проблему з продуктивністю, але зробило систему безпечнішою: помилки пристрою ставали помилками IOMMU і відновлюваними помилками I/O,
а не безшумною корупцією пам’яті. Потім вони вже правильно шукали реальні проблеми з затримкою: призначення IRQ, налаштування живлення і версії драйверів. «Оптимізація» виявилася просто зняттям запобіжників.

3) Сумно, але правильна практика, що врятувала ситуацію: контрольована авторизація + інвентаризація

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

Вони стандартизували конфігурацію прошивки: IOMMU увімкнено, Thunderbolt у режимі авторизації користувача, ніяких пристроїв до завантаження, і обмежили стани сну на ноутбуках,
щоб уникнути крайніх випадків «DMA під час сну». На Linux вони вимагали: нові Thunderbolt-пристрої з’являються як неавторизовані, доки користувач або адміністратор не схвалить їх.
На Windows вони перевіряли, що Kernel DMA Protection дійсно активний, а не просто «підтримується».

Одного дня підрядник підключив невідомий док у лабораторній зоні. Машина нічого не змонтувала і не впала; вона просто зафіксувала новий Thunderbolt-пристрій як
присутній-але-неавторизований. SOC отримав сповіщення з телеметрії кінцевої точки, що «новий зовнішній PCIe-пристрій намагався перерахуватися».
Реакція була швидкою й сумною: конфіскувати док, перевстановити образ машини з пересторогами і переглянути відеозаписи. Ніякого оповідання про злам — жодного драматизму.

Ось як виглядає «нудно», коли це працює: потенційно неприємна подія перетворюється на тикет і чек-лист. Ніхто не отримує бойову історію. Це і є мета.

Швидкий playbook діагностики: «вузьке місце» vs помилка vs межа довіри

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

Перш за все: доведіть, з яким лінком ви насправді узгодились

• Чи справді пристрій на Thunderbolt/PCIe, чи він упав у USB?
• Чи затримався він на низькій швидкості через кабель/ретаймер?
• Чи є петля повторного тренування PCIe лінку?

Друге: перевірте стан IOMMU/DMAR/IVRS і помилки

• Чи IOMMU увімкнено і активне?
• Чи є помилки IOMMU, що вказують на заблокований DMA (добре для безпеки, погано для сумісності пристроїв)?
• Чи пристрої згруповані так, що це перешкоджає ізоляції?

Третє: перевірте стан безпеки/авторизації Thunderbolt

• Чи пристрій авторизовано?
• Чи система у дозволяючому рівні безпеки?
• Чи поведінка до завантаження дозволяє надто ранню енумерацію?

Четверте: перевірте живлення та прошивку

• Чи не нестача живлення порту для корпусу з живленням від шини?
• Чи є відома погана ревізія прошивки контролера?
• Чи ви використовуєте «таємний кабель з конференції»?

Жарт №2: Найшвидший спосіб відлагодити Thunderbolt — замінити кабель; другий за швидкістю спосіб — прикинутися, що ви замінили кабель, і витратити дві години даремно.

Практичні завдання: перевірити, зміцнити та усунути неполадки (з командами)

Команди нижче орієнтовані на Linux, бо Linux показує правду у відкритому вигляді. Windows має еквіваленти (Device Manager, PowerShell, event logs),
але робочий процес діагностики однаковий: перевірити підтримку апаратури, політику прошивки, застосування в ОС, а потім протестувати на реальному пристрої.

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

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi|IVRS' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.000000] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c90780106f0462 ecap f020de
[    0.000000] DMAR: RMRR base: 0x0000000009f00000 end: 0x0000000009ffffff

Що це означає: «IOMMU enabled» вказує, що Intel VT-d активний. На AMD ви побачите рядки AMD-Vi/IVRS.
RMRR-області (зарезервована пам’ять) можуть натякати, що деякі пристрої потребують identity-mapping (може ускладнювати ізоляцію).
Рішення: Якщо ви нічого не бачите або бачите «IOMMU disabled», виправте BIOS/UEFI та параметри завантаження ядра перед подальшими діями.

Завдання 2: Підтвердити розширення віртуалізації CPU та можливість IOMMU

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-12900K
Virtualization:                  VT-x

Що це означає: VT-x — це підтримка віртуалізації CPU; це не VT-d. Але якщо VT-x є на сучасній платформі, VT-d часто теж присутнє.
Рішення: Тут не зупиняйтеся. Все ще потрібно перевірити VT-d/AMD-Vi у прошивці та dmesg.

Завдання 3: Перевірити рядок команд ядра на наявність IOMMU та режим passthrough

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

Що це означає: intel_iommu=on примусово вмикає VT-d; amd_iommu=on — еквівалент для AMD.
iommu=pt увімктає passthrough-відображення для продуктивності в деяких випадках, але це може зменшити переваги ізоляції для пристроїв, які не ремапляться явно.
Рішення: Для настільних ПК з Thunderbolt та безпековою позицією краще обирати повне ремапування (не використовувати iommu=pt), якщо немає виміряних причин.

Завдання 4: Перелічити пристрої Thunderbolt і їхній стан авторизації

cr0x@server:~$ boltctl
 ● Dell TB16 Dock
   ├─ type:          peripheral
   ├─ name:          Dell Thunderbolt Dock
   ├─ vendor:        Dell
   ├─ uuid:          2c1b8b50-8d41-4e1e-9f5a-5c6b0b2a1a1d
   ├─ status:        authorized
   ├─ stored:        yes
   └─ policy:        auto

Що це означає: «authorized» означає, що ОС дозволила його. «stored: yes» означає, що авторизація збережена.
Рішення: У середовищі з підвищеним ризиком встановіть політику на ручну авторизацію і зберігайте мінімум авторизованих пристроїв. Якщо з’являються невідомі пристрої, ставте це як інцидент, а не цікавинку.

Завдання 5: Переглянути рівень безпеки Thunderbolt, який показує ядро

cr0x@server:~$ cat /sys/bus/thunderbolt/devices/domain0/security
user

Що це означає: Поширені значення: none, user, іноді secure.
«user» зазвичай вимагає авторизації нових пристроїв.
Рішення: Якщо там none на системі, що використовується у спільних просторах, змініть налаштування BIOS/UEFI Thunderbolt і/або політику ОС. «none» — це «підключив і володію».

Завдання 6: Визначити, чи корпус «Thunderbolt» насправді використовує режим USB-зберігання

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 10000M

Що це означає: Якщо пристрій видно через USB з UAS, можливо, ви використовуєте USB 3.x, а не тунелювання PCIe/NVMe.
Рішення: Якщо продуктивність низька, перевірте, чи погодилися Thunderbolt чи USB. Деякі корпуси підтримують обидва режими і мовчки відкатуються.

Завдання 7: Перелічити PCIe-пристрої і знайти контролери Thunderbolt та мости

cr0x@server:~$ lspci -nn | egrep -i 'thunderbolt|usb4|dsl|jhl|maple|bridge'
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Що це означає: Ви бачите інтерфейс хоста Thunderbolt (NHI) і мости, що представляють тунельовану PCIe-ієрархію.
Рішення: Якщо ваш порт «Thunderbolt» взагалі не з’являється, підозрюйте вимкнення в BIOS, відсутні драйвери або платформу без фактичного Thunderbolt/USB4 тунелювання.

Завдання 8: Перевірити швидкість і ширину PCIe-лінку для пристрою (реальна продуктивність)

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

Що це означає: Пристрій здатний на 16GT/s x4, але зараз працює на 8GT/s x2. Це зменшення пропускної здатності.
Рішення: Перед тим як звинувачувати IOMMU, виправте фізичний рівень: кабель, док, порт, прошивка і живлення. Пониження лінку зазвичай — проблема шляху сигналу.

Завдання 9: Шукати спам PCIe Advanced Error Reporting (AER) — індикатор проблем з надійністю

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'AER|pcieport|DPC|fatal|Surprise Down' | tail -n 30
pcieport 0000:00:07.0: AER: Corrected error received: 0000:00:07.0
pcieport 0000:00:07.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
pcieport 0000:00:07.0: AER:   device [8086:1136] error status/mask=00001000/00002000
pcieport 0000:00:07.0: AER:    [12] Timeout

Що це означає: Виправлені помилки можуть бути пережиті, але вказують на проблеми з цілісністю сигналу. «Surprise Down» часто позначає відключення або подію живлення.
Рішення: Якщо AER-помилки корелюють із зависаннями, вважайте док/кабель/контролер підозрілими. Спочатку замініть кабель, потім оновіть прошивку і потестуйте інший док.

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

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; lspci -nns $(basename -a $g/devices/*); echo; done | head -n 40
IOMMU Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4660]

IOMMU Group 7
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Що це означає: Пристрої в одній IOMMU-групі не можна ізолювати один від одного. Деякі плати з’єднують половину чіпсету разом, що є проблемою.
Рішення: Для VFIO/passthrough вам може знадобитись підтримка ACS або інший апарат. Для безпеки великі групи означають ширшу зону ураження, якщо пристрій відображено.

Завдання 11: Перевірити наявність IOMMU-помилок (блоковані спроби DMA)

cr0x@server:~$ sudo dmesg | egrep -i 'iommu fault|DMAR:.*fault|AMD-Vi:.*Event' | tail -n 20
DMAR: [DMA Write NO_PASID] Request device [00:0d.2] fault addr 0x0000000f7c0000 [fault reason 0x05] PTE Write access is not set

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

Завдання 12: Переконатися, що hotplug Thunderbolt керується авторизацією (вид udev)

cr0x@server:~$ udevadm monitor --kernel --property
KERNEL[12345.678901] add      /devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0 (thunderbolt)
ACTION=add
SUBSYSTEM=thunderbolt
DEVPATH=/devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0
DEVNAME=/dev/thunderbolt0

Що це означає: Ви можете бачити події енумерації в реальному часі. Поєднайте це з boltctl, щоб спостерігати, чи з’являються нові пристрої як неавторизовані.
Рішення: Якщо пристрої з’являються повністю функціональними без авторизації в середовищі з високою безпекою, ваш рівень безпеки Thunderbolt занадто дозволячий.

Завдання 13: Підтвердити шлях пристрою NVMe (Thunderbolt PCIe проти USB mass storage)

cr0x@server:~$ lsblk -o NAME,TRAN,MODEL,SIZE,TYPE,MOUNTPOINT
NAME        TRAN   MODEL                 SIZE TYPE MOUNTPOINT
nvme0n1     pcie   Samsung SSD 980 PRO  931G disk
nvme1n1     pcie   External NVMe        1863G disk /mnt/ext
sda         usb    USB DISK             931G disk /mnt/usb

Що це означає: TRAN=pcie вказує, що ядро бачить його як NVMe/PCIe-пристрій (типово для справжніх Thunderbolt NVMe-корпусів).
TRAN=usb означає USB-зберігання.
Рішення: Якщо ви очікували PCIe, а отримали USB, перевірте узгодження кабелю/порту і режим корпусу.

Завдання 14: Виміряти реальну пропускну здатність і виявити тротлінг (перевірка сховища)

cr0x@server:~$ sudo fio --name=extseq --filename=/mnt/ext/testfile --size=4G --direct=1 --rw=write --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based
extseq: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=16
fio-3.36
...
WRITE: bw=1850MiB/s (1940MB/s), 1850MiB/s-1850MiB/s (1940MB/s-1940MB/s), io=55.3GiB (59.4GB), run=30666-30666msec

Що це означає: Це здоровий показник «швидкого зовнішнього NVMe» для багатьох конфігурацій Thunderbolt. Якщо ви бачите 300–500MB/s, можливо, ви в USB-режимі або лінк понижено.
Рішення: Використовуйте результати fio разом зі статусом лінку (Завдання 8), щоб вирішити, чи це проблема з сховищем, чи проблема узгодження з’єднання.

Завдання 15: Перевірити стани управління живленням, що спричиняють відключення пристроїв

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Що це означає: Агресивний ASPM може викликати проблеми лінку на маргінальному апаратному шляху.
Рішення: Якщо ви маєте сплески лінку/AER timeout, тимчасово спробуйте pcie_aspm=off. Якщо це виправляє стабільність, ви знайшли проблему сигналу/енергетичного запасу — тоді вибирайте між стабільністю та енергозбереженням.

Завдання 16: Перевірити еквівалентну політику для Windows (з боку Linux: перевірити, чи прошивка відкриває захист DMA)

cr0x@server:~$ sudo mokutil --sb-state
SecureBoot enabled

Що це означає: Secure Boot — це не IOMMU, але частина «ланцюга довіри від прошивки до ОС». На змішаних парках машини з вимкненим Secure Boot часто також мають інші ліберальні налаштування прошивки.
Рішення: Якщо ви не можете стандартизувати налаштування прошивки, ви будете ганятися за примарами: одна машина поводиться добре, інша — ні, і єдина різниця — тумблер у BIOS, який хтось змінив у 2022 році.

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

1) «Thunderbolt-зберігання повільне, як SATA»

Симптоми: ~300–550MB/s, велика затримка, непослідовна продуктивність.

Корінь проблеми: Корпус узгодив режим USB (UAS) замість тунелювання PCIe/NVMe, або PCIe-лінк понижено (x1/x2, менший GT/s).

Виправлення: Використайте lsusb -t і lsblk -o TRAN, щоб підтвердити транспорт. Перевірте статус лінку через lspci -vv. Замініть кабель/порт; оновіть прошивку дока/корпусу.

2) «Випадкові зависання при підключенні/відключенні»

Симптоми: Жорсткий лок, чорні екрани, kernel panic, іноді лише під час hotplug.

Корінь проблеми: Шторми AER, баги прошивки контролера або hotplug у поєднанні з агресивним ASPM/керуванням живленням.

Виправлення: Перевірте journalctl -k на наявність AER/DPC повідомлень. Потестуйте відомо-робочий кабель. Тимчасово встановіть pcie_aspm=off. Оновіть BIOS і прошивку контролера Thunderbolt.

3) «Усе зламалося після ввімкнення VT-d/IOMMU»

Симптоми: Док не розпізнається, пристрої зникають, завантаження довшає, дивна поведінка драйверів.

Корінь проблеми: Прошивка має биті DMAR-таблиці, потрібні ядрові обхідні шляхи, або пристрої залежать від identity-mapping, що змінюється під IOMMU.

Виправлення: Спочатку оновіть BIOS. Перегляньте dmesg на предмет DMAR/IOMMU помилок. Акуратно тестуйте параметри ядра (наприклад, примусове вмикання/вимкнення IOMMU для вендора). Якщо конкретний пристрій поводиться некоректно, вважайте його недовіреним і замініть.

4) «Ми налаштували безпеку Thunderbolt, але хтось все одно може підключити будь-який док»

Симптоми: Невідомі пристрої працюють одразу; немає запитів/журналів авторизації.

Корінь проблеми: Рівень безпеки Thunderbolt у BIOS встановлений як none, підтримка до завантаження увімкнена, або політика ОС не застосовується.

Виправлення: Перевірте /sys/bus/thunderbolt/devices/domain0/security і boltctl. Посиліть прошивкову політику: відключіть Thunderbolt до завантаження, вимагайте авторизацію користувача.

5) «eGPU працює, але продуктивність дивна і іноді GPU зникає»

Симптоми: Скиди GPU, тайм-аути драйвера, зниження ширини PCIe, переривчасті відключення під навантаженням.

Корінь проблеми: Нестабільність лінку, проблеми з подачею живлення або насичення контролера Thunderbolt під великим I/O разом з трафіком дисплея.

Виправлення: Перевірте ширину/швидкість лінку через lspci -vv. Перегляньте журнали ядра на наявність AER. Забезпечте достатнє живлення, використовуйте короткі сертифіковані кабелі і уникайте підключення багатьох пристроїв через один порт, якщо вам потрібна передбачувана затримка.

6) «Ми вважаємо, що повне шифрування диска робить DMA неактуальним»

Симптоми: Аргумент політики, а не збій: «ми ж зашифровані, отже безпечні».

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

Виправлення: Увімкніть IOMMU і функції захисту DMA; обмежте авторизацію Thunderbolt; зменшіть вікно впливу станів сну; застосуйте політику блокування екрана й підвищеної безпеки при переході в режим сну.

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

Чек-лист A: Зміцнення настільного ПК, що щоденно використовує доки Thunderbolt

1. Базова налаштування прошивки: увімкніть VT-d/AMD-Vi; увімкніть Secure Boot, якщо ваша організація це підтримує; оновіть BIOS до відомої доброї ревізії.
2. Рівень безпеки Thunderbolt: встановіть режим авторизації користувача (або найсуворіший підтримуваний); де можливо — відключіть Thunderbolt до завантаження.
3. Застосування ОС: на Linux переконайтесь, що безпека Thunderbolt не встановлена в none; використовуйте bolt для керування авторизацією; журналюйте події hotplug.
4. Перевірка IOMMU: підтвердіть у dmesg, що IOMMU увімкнено і що під час звичайного підключення немає безперервного спаму помилок.
5. Інвентар пристроїв: зберігайте та затверджуйте лише корпоративно затверджені доки; видаляйте застарілі авторизації для пристроїв, що більше не в обігу.
6. Тест на надійність: проводьте стрес-тести (fio для сховища, навантаження GPU для eGPU), спостерігаючи за AER-помилками і пониженням лінку.
7. Дисципліна з кабелями: стандартизуйте кабелі; маркуйте їх; уникайте довгих пасивних трас, що межують із запасом сигналу.
8. Хук для реагування на інциденти: розглядайте невідому енумерацію Thunderbolt як сигнал безпеки; не всі сигнали — інциденти, але всі сигнали потребують запису.

Чек-лист B: Якщо вам не потрібен Thunderbolt — позбудьтеся проблеми

1. Вимкніть тунелювання Thunderbolt/USB4 у BIOS/UEFI, якщо платформа це дозволяє.
2. Явно вимкніть підтримку Thunderbolt до завантаження.
3. Фізично заблокуйте порти на системах з високим ризиком (так, серйозно), якщо система розташована у неконтрольованому просторі.
4. Все одно тримайте IOMMU увімкненим, якщо ви віртуалізуєте або дбаєте про ізоляцію внутрішніх пристроїв.

Чек-лист C: Рішення щодо iommu=pt і налаштування продуктивності

1. Почніть із повного ремапування IOMMU (без режиму passthrough).
2. Вимірюйте: час завантаження, пропускну здатність I/O, робочі навантаження, чутливі до затримки.
3. Якщо продуктивність помітно постраждала, випробуйте iommu=pt лише на тестовій машині.
4. Повторно перевірте: помилки IOMMU, поведінку авторизації Thunderbolt і чи відповідає ваша безпекова позиція середовищу.
5. Прийміть рішення: якщо ваші настільні ПК піддаються недовіреному фізичному доступу, не жертвуйте захистом DMA заради невеликих вигод.

FAQ

1) Якщо я на настільному ПК (не ноутбук), чи Thunderbolt все одно є ризиком DMA?

Так. Різниця між десктопом і ноутбуком нічого не змінює стосовно PCIe. Настільні ПК можуть бути навіть більш уразливими, бо вони стоять в офісах, лабораторіях і загальних просторах з легким доступом до портів.

2) Чи увімкнення IOMMU завжди запобігає атакам DMA через Thunderbolt?

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

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

VT-x — це підтримка віртуалізації CPU. VT-d — це IOMMU (DMA remapping). Люди часто плутають їх. Для ізоляції DMA через Thunderbolt вам потрібен VT-d/AMD-Vi.

4) Чи IOMMU погіршить продуктивність на робочій станції?

Зазвичай це не помітно для звичайних десктоп-навантажень. Можуть бути крайові випадки (деякі робочі процеси з дуже низькою затримкою аудіо/відео або баги прошивки).
Вимірюйте перед оптимізацією і не «оптимізуйте», відключаючи засоби безпеки.

5) Я увімкнув VT-d, і мій док став нестабільним. Чи вимкнути VT-d?

Ні — принаймні не як перший крок. Оновіть BIOS і прошивку Thunderbolt, протестуйте з іншим кабелем/доком і перевірте dmesg на помилки IOMMU.
Якщо док працює лише коли захист DMA вимкнено, цей док сам про себе багато розказує.

6) Чи USB-C те саме, що Thunderbolt/USB4?

USB-C — це форма роз’єму. Thunderbolt і USB4 — це протоколи, що можуть працювати через нього. Безпека залежить від того, які протоколи узгоджуються.
Порт USB-C може бути «лише USB» (нижчий ризик DMA) або повноцінним тунелюванням PCIe (вищий ризик DMA).

7) Чи повне шифрування диска захищає від атак Thunderbolt?

Воно захищає дані у стані спокою. Коли ОС працює і розблокована, у RAM містяться секрети. DMA націлюється на RAM. Шифрування необхідне, але недостатнє.

8) Чи стани сну/гібернації змінюють ризик?

Стани сну можуть розширити вікно, коли пристрої залишаються під живленням і можуть взаємодіяти з пам’яттю або шинами несподіваним чином.
Гібернація (повністю вимкнено, пам’ять записана на диск) зазвичай безпечніша для моделі загроз з фізичним доступом — за умови, що шифрування диска надійне і машина дійсно повністю вимкнена.

9) Якщо я використовую лише корпоративні доки, чи можна пропустити авторизацію Thunderbolt?

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

10) Чи важливі групи IOMMU, якщо я не роблю VFIO passthrough?

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

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

Якщо ви експлуатуєте настільні ПК як важливі системи — тому що вони важливі — ставтеся до Thunderbolt і зовнішнього PCIe як до production-інтерфейсу:
швидкого, потужного і абсолютно здатного зіпсувати вам тиждень.

1. Визначте позицію: якщо вам не потрібен Thunderbolt — вимкніть його у прошивці. Якщо потрібен — увімкніть IOMMU і вимагайте авторизацію.
2. Стандартизуйте прошивку: документуйте налаштування BIOS/UEFI для VT-d/AMD-Vi і безпеки Thunderbolt; впровадьте їх у парку машин.
3. Підтвердіть з доказами: виконайте перевірки dmesg/boltctl/lspci вище і збережіть результати як базову довідку.
4. Виправте фізичний рівень: припиніть відлагодження «випадкових» помилок за допомогою випадкових кабелів. Купуйте відомі хороші кабелі, маркуйте їх та виводьте з експлуатації прокляті екземпляри.
5. Інструментуйте межу: журналюйте додавання пристроїв Thunderbolt і події авторизації. Невідомі пристрої мають автоматично створювати тикет.

Настільні ПК не сервери, але в них зберігаються ключі до вашого королівства. Зовнішній PCIe — це межа привілеїв. Поводьтеся відповідно.

Що насправді означає «чисті IOMMU групи» (і навіщо це вам)

IOMMU група — це найменший набір PCIe‑пристроїв, який ваша платформа може надійно ізолювати для DMA (direct memory access). Якщо два пристрої ділять групу, ядро припускає, що їх не можна безпечно розділити, бо апаратне забезпечення не надає необхідних меж доступу між ними.

«Чисті» групи на практиці означають:

• Цільовий пристрій один у своїй групі (або лише в парі з нешкідливою функцією, яку також можна передати, наприклад HDMI‑аудіо GPU).
• Без несподіваних сусідів, як контролер SATA, USB‑контролер або кореневий порт чіпсету, що тягне за собою половину плати в ту саму групу.
• Стабільні групи між перезавантаженнями, оновленнями BIOS і ядра — бо ваш продакшн‑хост не має дружити з недовірою.

Чому це важливо: VFIO passthrough залежить від правильної межі IOMMU. Якщо ви передаєте пристрій, який ділить IOMMU групу з пристроєм, що все ще використовується хостом, у вас є три погані опції:

1. Не передавати його («сумно, але безпечно»).
2. Передати всю групу (іноді прийнятно, часто неможливо).
3. Використати ACS override, щоб підтасувати розділення (іноді працює, знижує гарантії ізоляції і може створити дивні режими відмови).

Чисті групи — це особливість материнської плати, а не трюк Linux. Linux лише повідомляє те, що платформа показує.

Жарт №1: Якщо ваш GPU ділить IOMMU групу з USB‑контролером, вітаю — ваша миша тепер «графічний аксесуар».

Як формуються IOMMU групи: CPU root‑порти, чіпсет і ACS

Ментальна модель: дерево з пунктами контролю

PCIe — це ієрархія. Ваш CPU забезпечує root‑комплекси й root‑порти. Чіпсет (PCH у Intel, «чіпсет» на платформах AMD) підключається до CPU і додає більше downstream‑портів, SATA, USB та інші інтегровані контролери.

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

Лінії CPU: найчистіша нерухомість

Пристрої, підключені безпосередньо до root‑портів CPU, зазвичай мають кращі групування, ніж пристрої за чіпсетом. Тому «GPU у верхньому x16 слоті, підключеному до CPU» — це не лише рекомендація по продуктивності, а й рекомендація по ізоляції.

На сучасних платформах CPU зазвичай пропонує:

• Один x16 (часто бікфуркатований як x8/x8 або x8/x4/x4) для GPU/HBA/NVMe‑каркасів
• Один або кілька x4 лінків для NVMe
• Лінк до чіпсету

Кожен з них — окремий шлях, де природно можуть утворюватися межі IOMMU груп.

Лінії чіпсету: більше портів — більше шарингу

Чіпсет — це пристрій‑«вентилятор», підключений до CPU одним аплінком (DMI у Intel, аналогічна концепція у AMD). Багато вбудованих пристроїв підвішені на чіпсеті: додаткові NVMe слоти, контролери SATA, USB, Wi‑Fi, 2.5GbE, іноді навіть PCIe‑слот.

Це означає дві речі:

• Пристрої, підключені через чіпсет, можуть частіше опинятися в спільних IOMMU групах, особливо якщо мости не мають ACS або прошивка конфігурує консервативно.
• Навіть якщо групи «достатньо чисті», інтенсивний I/O на пристроях чіпсету може конкурувати по каналу аплінку і виглядати як проблема IOMMU, коли насправді це насичення каналу.

ACS: функція, яку ви хочете, і чекбокс, якого може не бути

ACS існує в кількох формах (source validation, P2P request redirect, completion redirect, upstream forwarding). У практичних термінах VFIO ви хочете, щоб платформа виставляла достатньо ACS, щоб downstream‑пристрої можна було відокремити в свої окремі групи.

Деякі плати показують в BIOS такі перемикачі:

• Above 4G decoding (часто потрібно для великих BAR GPU та для стабільного passthrough)
• Resizable BAR (іноді покращує продуктивність; також може ускладнювати скиди і відображення в деяких стеках)
• IOMMU / SVM (AMD) або VT-d (Intel)
• ACS увімкнути/вимкнути або опція «PCIe ARI/ACS» (рідше на споживчих платах)
• PCIe bifurcation для кожного слота

Вендори плат не стандартизують назви. Половина роботи — знати синоніми для пошуку в BIOS.

Не плутайте «групування» з «підключенням ліній»

Підключення ліній визначає пропускну здатність і місце підключення (CPU vs чіпсет). Групування IOMMU стосується меж ізоляції. Вони корелюють, але не ідеально. Я бачив плати з відмінною проводкою ліній, але жахливим групуванням через те, що прошивка не відкрила ACS належним чином. Навпаки, бачив споживчі плати з дивно хорошими групами, бо root‑порти CPU були чистими, а мости чіпсету реалізували ACS коректно.

Ознаки при покупці: на що звертати увагу перед покупкою

1) Віддайте пріоритет слотам, що підключені до CPU, для пристроїв, які плануєте передавати

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

• Пасстру основного GPU: верхній x16 слот, приєднаний до CPU.
• Другий GPU / швидкісний NIC: другий слот, підключений до CPU (x8), якщо є.
• NVMe passthrough: M.2 підключений до CPU (часто в керівництві позначено як «from CPU», якщо пощастить).
• HBA passthrough: слот, підключений до CPU, якщо вам важлива чистота груп і передбачувані скиди.

Якщо плата має тільки один слот, підключений до CPU, а все інше йде через чіпсет, ваше IOMMU‑життя швидко ускладниться.

2) Вимагайте явної підтримки в BIOS для IOMMU/VT‑d і Above 4G decoding

Якщо в мануалі, скріншотах BIOS або на форумах підтримки не видно перемикачів для:

• IOMMU / SVM (AMD) або VT‑d (Intel)
• Above 4G decoding

…йдіть геть. «Ймовірно, воно є» — це те, як ви опиняєтеся з ACS override і переконуєте себе, що все нормально, бо сервер «не на публіці». Це не модель безпеки; це оптимізм.

3) Шукайте ознаки робочої станції: bifurcation, дружність до SR‑IOV, стабільна прошивка

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

• Налаштування PCIe bifurcation на слот (x16 → x8/x8, x8/x4/x4), щоб використовувати NVMe‑карти‑носії без PCIe‑світча.
• Стабільна тактика AGESA/ME‑прошивки, де оновлення не змінюють випадково PCIe‑перерахунок.
• Краще звітування помилок (WHEA логи, поведінка AER) і менше «ігрових оптимізацій».

4) Розумійте, що інтегровані контролери можуть «запоїти» групи

Материнські плати люблять додавати «корисні» контролери за спільними містками: додаткові SATA‑чіпи, додаткові USB‑контролери, Wi‑Fi, RGB‑контролери, іноді навіть Thunderbolt‑доповнення. Кожен додатковий пристрій може приклеїтися до групи, яку ви хотіли б тримати чистою.

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

• Якщо хочете чисті групи, не купуйте плату з купою «фішок». Купуйте плату з більшою кількістю нудних компонентів.
• Віддавайте перевагу Intel NIC (або серверним Broadcom) над випадковими «геймерськими» NIC, якщо це серйозно. Це не строго про IOMMU, але зменшує хаос драйверів.
• Уникайте плат, які пропускають другий «x16» слот через чіпсет, попри те, що він механічно x16. Механічний — не означає електричний.

5) Перевіряйте звіти спільноти, але ставтеся до них як до прогнозу погоди

Звіти користувачів про IOMMU групи корисні, але не догма. Версія BIOS, покоління CPU і навіть які M.2 слоти заповнені можуть змінити топологію. Використовуйте звіти для створення шорт‑ліста, а не для підписання замовлення на покупку.

6) Вирішіть зараз: ви приймаєте ACS override чи ні?

ACS override у Linux може розділити групи, прикидаючись, що ACS існує там, де його немає. Це інструмент; це також компроміс. В середовищах, де ізоляція має значення (multi‑tenant, неперевірені навантаження, відповідність), вважайте його неприйнятним.

В одиночному homelab‑сценарії, де ви довіряєте своїм VM і прагнете функціональності, це може бути «достатньо», але ставтеся до цього як до тимчасової лісі, а не до фундаменту.

7) Плануйте скиди і обробку квірків (особливо для GPU)

Чисті групи — не єдина «плата‑залежна» частина passthrough. Поведінка скиду GPU, підтримка FLR (Function Level Reset) і енергетичні налаштування платформи можуть визначати, чи перезавантажиться VM чисто або «застрягне» пристрій до перезавантаження хоста.

Якщо купуєте спеціально для GPU passthrough, схиляйтеся до:

• Платформ, відомих хорошою поведінкою з вашим вендором GPU (AMD/NVIDIA/Intel ARC) під VFIO
• Плат з менше сторонніх PCIe‑світчів і меншою кількістю «хитрих» шарингів ліній

Поради по платформі: AMD vs Intel, споживчі vs робочі станції vs сервери

AMD споживчі (AM4/AM5): часто хороші групи, іноді рулетка прошивки

Мейнстрим‑платформи AMD можуть виявитися надзвичайно дружніми до VFIO. Багато AM4 плат здобули репутацію за пристойне групування IOMMU, особливо коли GPU і основний NVMe підключені до CPU. AM5 продовжує цю тенденцію, але вводить новішу прошивку і складнішу поведінку PCIe 5.0.

Що віддавати перевагу:

• Плати, які ясно документують, які M.2 слоти підключені до CPU, а які — до чіпсету
• BIOS, що показує IOMMU, SVM, Above 4G і налаштування bifurcation по слотах
• Менше вбудованих контролерів, якщо вам важлива чистота груп

Чого уникати:

• Плат з «додатковими» PCIe‑містками заради косметичної кількості слотів
• Прошивки, що ховають розширені PCIe‑налаштування за «EZ mode forever»

Intel споживчі (LGA1200/1700/1851‑ish): VT‑d зрілий; фан‑аут чіпсету може створювати проблеми

Intel VT‑d зрілий. Більшість проблем не в VT‑d як такому; проблема в тому, як плата прокладає пристрої через PCH і чи відкриває прошивка достатній ACS. Intel‑споживчі плати часто мають багато пристроїв на чіпсеті: Wi‑Fi, кілька M.2, кілька USB‑контролерів, іноді підтримку Thunderbolt.

Що віддавати перевагу:

• Плати з сильними BIOS‑опціями для VT‑d, Above 4G decoding і bifurcation
• Чіткі діаграми підключення слотів у мануалі

Чого уникати:

• Thunderbolt‑доповнення, якщо вони вам не потрібні (вони додають додаткові мости і питання безпеки)
• «Геймерські» плати з купою контролерів за спільними містками

Платформи для робочих станцій (Threadripper/WRX80, Xeon W): нудно, дорого і зазвичай правильно

Якщо вам потрібно кілька пристроїв для passthrough без компромісів — кілька GPU, кілька NIC, HBA та NVMe — платформи для робочих станцій — це дорослий вибір. Ви купуєте більше ліній CPU, більше root‑портів і платформу, що очікує віртуалізації.

Що ви отримуєте:

• Більше PCIe‑слотів підключених до CPU (менше залежності від чіпсетного фан‑ауту)
• Кращі шанси на чисті групи без ACS override
• Часто краща підтримка SR‑IOV і корпоративних мережевих карт

Чим це обходиться:

• Гроші, звісно
• Енергоспоживання і складність охолодження
• Іноді повільніша динаміка споживчих фішок (бо стабільність — це фіча)

Серверні платформи: найкраща ізоляція, але не думайте, що «сервер» = «дружній для passthrough»

Серверні плати часто надають відмінну ізоляцію, але аудиторія зазвичай орієнтована на PCIe‑пристрої, якими керує хост, а не на передачу у довільні десктопні VM. Ви можете зіткнутися з:

• Дефолтами BIOS, які віддають пріоритет віддаленому керуванню та стабільності над споживчим комфортом
• Вбудованими пристроями, які важко відключити (BMC, додаткові мости)
• Особливостями з конс’юмерськими GPU (стани живлення, ініціалізація, відсутність підтримки option ROM)

Якщо ви робите GPU passthrough на серверній платі, рано перевіряйте конкретну модель GPU та поведінку при скиді.

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

Цікаві факти та коротка історія (щоб дивність стала зрозумілою)

• Факт 1: IOMMU в AMD брендується як AMD‑Vi; еквівалент Intel — VT‑d. Обидва вирішують ту саму основну проблему: контроль DMA пристроїв.
• Факт 2: PCIe ACS не завжди був поширений у споживчому сегменті; ранні прихильники VFIO часто спиралися на хаки чіпсету та патчі ядра.
• Факт 3: Фреймворк Linux VFIO з’явився як чистіший шлях у порівнянні з застарілими методами, підкреслюючи призначення пристрою з IOMMU як межі безпеки.
• Факт 4: «Above 4G decoding» — стара концепція: вона потрібна, бо PCIe‑пристрої потребують адресного простору для MMIO BAR, а сучасні GPU можуть вимагати багато.
• Факт 5: Resizable BAR (фіча PCIe) стала масовою з сучасними GPU; вона змінює обсяг VRAM, відображений у адресному просторі CPU, що може впливати на passthrough‑налаштування.
• Факт 6: PCIe bifurcation не гарантується формою слота; це функція платформи/прошивки. Два x8 пристрої в одному x16 слоті — рішення BIOS.
• Факт 7: «Чіпсетний аплінк» (Intel DMI або еквівалент) — це спільна труба; швидкий NVMe за чіпсетом може наситити її і виглядати як латентні примари.
• Факт 8: FLR (Function Level Reset) — це можливість PCIe, яка робить passthrough‑пристрої більш дружніми до життєвого циклу VM. Багато пристроїв все ще погано її реалізують.
• Факт 9: Склад IOMMU груп може змінюватися при заповненні певних M.2 слотів, бо плата може перемаршрутовувати лінії або вмикати інші мости.

Одна перефразована ідея, яку люди з операцій повторюють, бо вона постійно вірна: перефразована ідея — W. Edwards Deming (перефразовано): «Погана система переможе хорошу людину щоразу.»

Командний preflight: 12+ практичних завдань і як вирішувати за результатами

Ці завдання припускають Linux‑хост (Debian/Ubuntu/Proxmox типово). Вони створені, щоб швидко відповісти на три питання:

1. Чи IOMMU справді увімкнено?
2. Які IOMMU групи існують?
3. Чи можна безпечно прив’язати цільовий пристрій до vfio‑pci без шкоди для хоста?

Завдання 1: Підтвердити CPU‑флаги віртуалізації

cr0x@server:~$ lscpu | egrep 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-13900K
Virtualization:                  VT-x

Що це означає: VT‑x/AMD‑V — це CPU‑віртуалізація. Потрібна, але недостатня для passthrough пристроїв.

Рішення: Якщо віртуалізація відсутня, спочатку увімкніть CPU‑віртуалізацію в BIOS. Не думайте про IOMMU доти.

Завдання 2: Підтвердити підтримку IOMMU і чи воно увімкнено при завантаженні

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.210000] DMAR: Intel(R) Virtualization Technology for Directed I/O

Що це означає: «DMAR: IOMMU enabled» (Intel) або «AMD‑Vi: IOMMU enabled» (AMD) — зелений сигнал.

Рішення: Якщо бачите «IOMMU disabled» або нічого релевантного, увімкніть VT‑d/IOMMU у BIOS і додайте параметри ядра.

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

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

Що це означає: Для Intel — intel_iommu=on. Для AMD зазвичай — amd_iommu=on. iommu=pt часто використовується, щоб зменшити накладні витрати для хост‑пристроїв (pass‑through режим для не‑призначених пристроїв).

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

Завдання 4: Перерахувати IOMMU групи (найкорисніша команда)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; for d in "$g"/devices/*; do lspci -nn -s "${d##*/}"; done; echo; done | less
IOMMU Group 16
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

IOMMU Group 17
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

IOMMU Group 18
00:14.0 USB controller [0c03]: Intel Corporation USB 3.2 Controller [8086:7ae0]
00:14.2 RAM memory [0500]: Intel Corporation Shared SRAM [8086:7aa7]

Що це означає: Ваш GPU — чистий (тільки власні функції). NVMe — один. USB‑контролер згрупований з функцією чіпсету (нормально).

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

Завдання 5: Зіставити фізичний слот зі PCIe‑адресою

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvme|ethernet'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]

Що це означає: PCI‑адреси (domain:bus:slot.function) — це те, як ви ідентифікуєте пристрої для біндингу і passthrough.

Рішення: Запишіть адреси пристроїв, які збираєтеся передавати.

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3901
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Хост зараз використовує GPU через nvidia.

Рішення: Якщо ви хочете passthrough, хост не повинен використовувати пристрій. Плануйте прив’язати його до vfio-pci рано в процесі завантаження.

Завдання 7: Визначити vendor/device ID для прив’язки vfio‑pci

cr0x@server:~$ lspci -nn -s 01:00.0 -s 01:00.1
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

Що це означає: Ви будете прив’язувати 10de:2484 і 10de:228b до vfio‑pci.

Рішення: Завжди прив’язуйте всі функції в одній групі (наприклад GPU + аудіо), якщо у вас немає конкретної причини інакше.

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

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          73728  1 vfio_pci
vfio_iommu_type1       40960  0
vfio                   24576  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             442368  0
kvm                  1306624  1 kvm_intel

Що це означає: Ядро має завантажений VFIO.

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

Завдання 9: Сухий запуск прив’язки за допомогою driver_override (тест у runtime)

cr0x@server:~$ echo vfio-pci | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver_override
vfio-pci
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind
0000:01:00.0
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/bind
0000:01:00.0

Що це означає: Ви можете прив’язати пристрій до vfio‑pci у runtime. Якщо не вдається — пристрій може бути зайнятий або заблокований груповими обмеженнями.

Рішення: Якщо runtime‑прив’язка не вдається, не робіть її постійною ще. Усуньте причину (консоль використовує GPU, framebuffer, аудіо тощо).

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

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Драйвер хоста більше не приєднаний; vfio‑pci контролює пристрій.

Рішення: Тепер ви можете налаштувати гіпервізор для призначення пристрою VM.

Завдання 11: Перевірити підказки про ACS/PCIe AER у логах ядра, коли групи виглядають неправильно

cr0x@server:~$ dmesg | egrep -i 'ACS|AER|PCIe|Downstream|Upstream' | head -n 40
[    0.812345] pci 0000:00:1c.0: PCIe Downstream Port
[    0.812678] pci 0000:00:1c.0: ACS not supported
[    0.900123] pcieport 0000:00:1c.0: AER enabled with IRQ 122

Що це означає: Downstream‑порт не підтримує ACS; це може змушувати групуватися.

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

Завдання 12: Визначити, чи пристрій підтримує скидання (FLR) і як він поводиться

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'Capabilities: \[.*\] Express|FLR|Reset' -n
45:Capabilities: [68] Express (v2) Endpoint, MSI 00
92:	DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
130:	Capabilities: [100] Advanced Error Reporting
161:	Capabilities: [250] Latency Tolerance Reporting

Що це означає: Не всі пристрої явно рекламують FLR простим grep‑ом, і квірки скиду GPU поширені.

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

Завдання 13: Перевірити huge BAR / тиск адресного простору (поширено з сучасними GPU)

cr0x@server:~$ dmesg | egrep -i 'BAR|resizable|MMIO|above 4g' | head -n 50
[    1.234567] pci 0000:01:00.0: BAR 0: assigned [mem 0x6000000000-0x600fffffff 64bit pref]
[    1.234890] pci 0000:01:00.0: BAR 2: assigned [mem 0x6010000000-0x6011ffffff 64bit pref]
[    1.235012] pci 0000:01:00.0: enabling device (0000 -> 0003)

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

Рішення: Якщо бачите помилки BAR‑призначення або пристрої не з’являються, увімкніть Above 4G decoding; тимчасово відключіть Resizable BAR під час налагодження.

Завдання 14: Перевірити, які пристрої за чіпсетом, а які — за CPU (вигляд топології)

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0  Intel Corporation Device 1234
           +-01.0-[01]----00.0  NVIDIA Corporation GA104 [GeForce RTX 3070]
           +-02.0-[02]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller
           +-14.0  Intel Corporation USB 3.2 Controller
           \-1c.0-[03]----00.0  Intel Corporation I210 Gigabit Network Connection

Що це означає: Дерево допомагає побачити, чи пристрій висить за певним root‑портом/мостом. Пристрої за одним downstream‑портом частіше ділять групу, якщо ACS слабкий.

Рішення: Віддавайте перевагу пристроям для passthrough, що прямо підключені під окремі root‑порти.

Завдання 15: Перевірити, що ваш initramfs прив’яже vfio рано (щоб хост не захопив пристрої)

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

Що це означає: Конфігурація існує для ранньої прив’язки ID до vfio‑pci.

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

Завдання 16: Перебудувати initramfs і підтвердити, що це пройшло успішно

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-amd64

Що це означає: Ваш ранній середовищний образ тепер містить конфіг для прив’язки VFIO.

Рішення: Перезавантажте і перевірте знову Завдання 6/10, щоб переконатися, що vfio‑pci володіє пристроєм під час завантаження.

Швидкий план діагностики: що перевірити першим/другим/третім, щоб швидко знайти вузьке місце

Перше: IOMMU увімкнено і працює?

• Перевірте /proc/cmdline на intel_iommu=on або amd_iommu=on (Завдання 3).
• Перевірте dmesg на DMAR/AMD‑Vi enabled (Завдання 2).
• Якщо відсутнє: BIOS‑перемикачі (VT‑d/IOMMU, Above 4G) і параметри ядра. Перезавантажте.

Друге: чи IOMMU групи роблять passthrough можливим?

• Здампіть IOMMU групи (Завдання 4).
• Знайдіть групу цільового пристрою і перелічіть все, що в ній.
• Якщо група містить критичні для хоста пристрої (USB‑контролер потрібний для клавіатури на headless, boot NVMe, основний NIC): не продовжуйте.

Третє: чи стабільна поведінка скиду/прив’язки пристрою?

• Перевірте володіння драйвером (lspci -k) (Завдання 6/10).
• Спробуйте runtime bind/unbind (Завдання 9).
• Спостерігайте dmesg під час старту/зупинки VM на предмет помилок (Завдання 11/13).
• Якщо перезавантаження VM «застрягло» пристрій: у вас проблема скиду, а не групування.

Четверте: це справді проблема IOMMU чи проблема пропускної здатності/латентності?

• Використайте lspci -t, щоб побачити, чи ваші «швидкі» пристрої всі за чіпсетним аплінком (Завдання 14).
• Якщо ви насичуєте аплінк чіпсету, перемістіть високонавантажені пристрої на лінії CPU або прийміть обмеження.

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

1) Симптом: GPU ділить групу з USB/SATA/NIC

Коренева причина: GPU знаходиться за мостом без ACS або за чіпсетом, який не може ізолювати пристрої; іноді слот підключений через чіпсет.

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

2) Симптом: IOMMU групи виглядають нормально, але запуск VM падає з «device is in use»

Коренева причина: Драйвер хоста захопив пристрій дуже рано (framebuffer, аудіо, драйвер вендора GPU).

Виправлення: Прив’яжіть ID пристрою до vfio-pci у конфігах modprobe і перебудуйте initramfs (Завдання 15/16). Переконайтеся, що хост не використовує GPU для консолі.

3) Симптом: VM запускається один раз; другий запуск зависає або GPU зникає до перезавантаження хоста

Коренева причина: Проблеми зі скидом/FLR; поширені для деяких GPU і певної поведінки енергоменеджменту плати.

Виправлення: Спробуйте інший слот (інший root‑порт). Вимкніть агресивний ASPM у BIOS. Розгляньте модулі для reset від вендора, де застосовно. У найгіршому випадку — оберіть іншу модель GPU, відому коректним скиданням.

4) Симптом: Увімкнення Above 4G decoding ламає завантаження або ховає пристрої

Коренева причина: Баг прошивки або конфліктні налаштування (CSM, legacy option ROM, дивна PCIe‑мапінг).

Виправлення: Вимкніть CSM/legacy boot, використайте UEFI. Оновіть BIOS. Якщо проблема лишається — плата показує, ким вона є — повірте їй.

5) Симптом: NVMe passthrough працює, але під навантаженням продуктивність нестабільна

Коренева причина: NVMe підключений через чіпсет і конкурує на аплінку; це не проблема IOMMU групування.

Виправлення: Перемістіть NVMe на CPU‑підключений M.2 або використайте слот CPU з каркою‑носієм (з bifurcation). Або прийміть обмеження аплінку і скоригуйте очікування.

6) Симптом: SR‑IOV «працює», але VF опиняються в дивних групах або не призначаються

Коренева причина: Обмеження прошивки/драйвера NIC, межі відображення IOMMU або поведінка ACS навколо PF/VF.

Виправлення: Оновіть прошивку NIC. Перевірте, що IOMMU увімкнено і поведінку iommu=pt. Віддавайте перевагу серверним/робочим платам і NIC, відомим стабільністю SR‑IOV.

Жарт №2: ACS override — це як позначити свій ящик для дрібниць «організовано». Воно може зменшити стрес, але не змінює фізики.

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

Крок 1: Визначте, що саме будете передавати (будь‑ласка, конкретно)

• Які GPU? Включно з аудіофункцією.
• Які NVMe? Boot vs passthrough.
• Які NIC? Потрібен SR‑IOV?
• Будь‑який passthrough USB‑контролер (для VR, донглів, ліцензійних ключів)?

Крок 2: Оберіть платформу, виходячи з потреб по лініях, а не з виду

• Один GPU + один NVMe passthrough: багато споживчих плат з цим впораються.
• Два GPU + кілька NVMe/NIC/HBA для passthrough: орієнтуйтеся на робочі станції (більше ліній CPU, більше root‑портів).
• Відповідність або неперевірені VM: уникайте ACS override як стратегії.

Крок 3: Чекліст при виборі материнської плати (до покупки)

• Мануал показує проводку слотів (CPU vs чіпсет) і правила шарінгу ліній.
• BIOS підтримує: IOMMU/VT‑d, Above 4G decoding, per‑slot bifurcation.
• Менше сторонніх контролерів, якщо вони вам не потрібні.
• Звіти про чисті IOMMU групи на схожих CPU/BIOS версіях (як підказка, не як доказ).
• Фізичне розташування дозволяє охолодження при заповненні декількох PCIe‑слотів.

Крок 4: Зберіть і валідуйте на столі (до міграції важливих сервісів)

1. Встановіть хост‑ОС.
2. Увімкніть налаштування BIOS (IOMMU/VT‑d, 4G decoding, UEFI boot).
3. Завантажтеся і виконайте Завдання 2–4, щоб перевірити IOMMU групи.
4. Прив’яжіть спочатку некритичний пристрій (запасний NIC або USB‑контролер) до VFIO, щоб перевірити потік VFIO.
5. Тільки потім прив’язуйте GPU/NVMe, що вас цікавлять.

Крок 5: Закріпіть налаштування (щоб відтворювалося)

• Зафіксуйте версію BIOS і налаштування (скріншоти або текст).
• Прив’яжіть версію ядра, якщо стабільність важливіша за новизну.
• Тримайте відомий‑good пункт завантаження у завантажувачі.
• Документуйте PCI‑адреси і IOMMU групи як частину нотаток щодо збірки хоста.

Три міні‑історії з корпоративного життя (що фактично йде не так)

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

Вони збирали невеликий кластер для внутрішнього графічного пайплайну: кілька потужних хостів, по кілька GPU на кожен, і дедлайн, що вже був емоційно нестабільним. Хтось вибрав материнську плату за відгуками «чудово для ігор, купа PCIe слотів». Насправді в ній було багато слотів. Електрично — амбіції були скромні.

Перший хост підняли і команда зробила те, що робить кожен: увімкнули VT‑d/IOMMU, Above 4G decoding, поставили гіпервізор і спробували передати GPU. Одна GPU виглядала нормально. Друга GPU поділила IOMMU групу з USB‑контролером і SATA‑контролером. Передача цієї групи забрала б завантажувальний диск хоста і його віддалену клавіатуру.

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

Постмортем був простий і болісний: команда припустила, що кількість слотів означає незалежні root‑порти і межі ACS. Це не так. Механічні x16 слоти дешеві; чисті IOMMU межі — ні.

Вони замінили плати на робочо‑станційного класу з меншою кількістю «фішок» і більшою кількістю ліній. Все стало нудним. Ніхто не жалкує про втрату RGB.

Історія 2: Оптимізація, що зіграла злий жарт

Інша команда вела приватний хмарний проект зі змішаними вузлами обчислень і зберігання. Вони хотіли максимізувати щільність: більше NVMe, більше NIC і ще слот для випадкового GPU тесту. «Оптимізація» була у використанні PCIe‑світча, щоб розгорнути лінії і втиснути більше пристроїв у меншу кількість root‑портів CPU.

На папері — елегантно: один x16 слот ставав чотирма x4 NVMe плюс NIC деінде. На практиці PCIe‑світч привніс поведінку групування, яка їх здивувала. Декілька кінцевих точок опинилися в одній IOMMU групі, бо upstream‑порт не виставляв ACS у той спосіб, як Linux очікує. Плани passthrough швидко ускладнилися.

Вони намагалися пройти через: передавали цілі групи, переміщали пристрої, перемикали BIOS‑налаштування і сперечалися, чи важливий перфоманс від iommu=pt для їхнього навантаження. Зрештою, їм вдалося запустити щось — але кожне оновлення ядра ставало ризиком. Порядок нумерації змінився одного разу, і конфіг VM, що спирався на адресу пристрою, опинився з неправильним NVMe. Це виявили на стейджингу, але це було гучним попередженням.

Виправлення було нудним: вони перестали оптимізувати щільність слотів і почали оптимізувати ізоляцію. Використали менше свічів, більше прямих ліній CPU і погодилися на трохи більший розмір вузла. Бізнес‑вихід — краща доступність і менше ночних розслідувань «чому змінилася група 27?».

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

Організація, близька до фінансів, мала невеликий набір гіпервізорів, що хостили внутрішні робочі столи з GPU‑прискоренням. Нічого публічного в інтернеті, але все одно чутливо. Їх SRE‑лідер мав правило: кожна апаратна платформа проходить «hardware acceptance test» перед допуском у флот.

Тест не був гламурним. Це був скрипт, що дампив IOMMU групи, знімав lspci -t, фіксував налаштування BIOS і перевіряв, чи цільові пристрої можуть прив’язатися до vfio‑pci без ACS override. Також вони вимагали повний життєвий цикл VM: завантаження, завантаження драйвера, короткий стрес, перезавантаження VM, повтор. Якщо GPU зависав при перезавантаженні, ця модель GPU або слот відкидалися.

Одного кварталу постачальник пообновив BIOS і acceptance test провалився на новій партії машин: другий NVMe тепер ділив групу з USB‑контролером чіпсету. Для звичайного десктоп‑використання нічого «не ламалося». Для passthrough — це був неприйнятний стан.

Оскільки у них був тест і вони запускали його перед розгортанням, вони виявили проблему рано, затримали оновлення BIOS і підняли питання до вендора з чистими доказами: до/після карти груп і топології. Флот залишився стабільним. Зміна виправлена в наступному BIOS. Найцікавіше в інциденті було те, що нікому не довелося нічого робити пізно вночі.

Ось секрет: нудні перевірки запобігають хвилюючим аваріям.

FAQ

1) Яка «хороша» компоновка IOMMU груп для GPU passthrough?

Ідеал: GPU одинокий разом зі своєю аудіофункцією у тій же групі. Прийнятно: GPU ділиться з upstream‑мостом, який ви теж можете передати (рідко і залежить від випадку). Погано: GPU ділиться з USB/SATA/NIC, які потрібні хосту.

2) Чи дорожча материнська плата гарантує чисті групи?

Ні. Ціна купує фічі і іноді валідацію, але не гарантує розумну PCIe‑топологію. Плати для робочих станцій зазвичай краще, бо мають більше ліній CPU і більше root‑портів, а не через кращі радіатори.

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

Воно знижує гарантії ізоляції, змушуючи ядро вважати пристрої відокремленими, навіть якщо фабрика не може це забезпечити. У довірених одноосібних середовищах це може бути прийнятним. У multi‑tenant або чутливих до безпеки середовищах — неприйнятно.

4) Чому мої IOMMU групи змінюються при заповненні M.2 слота?

Тому що деякі плати шарять лінії між слотами або вмикають інші мости залежно від того, які слоти заповнені. Додавання NVMe може змінити, як будується PCIe‑дерево, що змінює групування.

5) Чи завжди пристрої, підключені через чіпсет, погані для passthrough?

Не завжди. Деякі чіпсети/плати показують адекватну ACS‑поведінку і дають робочі групи. Більший ризик — спільна пропускна здатність аплінку і забруднення груп іншими пристроями чіпсету.

6) Чи потрібен Above 4G decoding для passthrough?

Часто так, особливо з сучасними GPU (великі BAR) або багатьма PCIe‑пристроями. Без нього ви можете бачити помилки при перерахунку пристроїв або BAR‑помилки.

7) Чи можу я передати лише GPU, а не його аудіофункцію?

Можете спробувати, але зазвичай чистіше передавати всі функції в групі. Розділення функцій може створити конфлікти драйверів або залишити хост‑драйвери, що «чіпають» пристрій.

8) Чому passthrough GPU працює до перезавантаження VM?

Це зазвичай проблема скиду (FLR не підтримується або працює неправильно; квірки енергоменеджменту). Спробуйте інший слот, змініть енергетичні налаштування BIOS або оберіть апарат, відомий коректними скидами.

9) Який найпростіший спосіб протестувати материнську плату на чисті групи перед покупкою?

Завантажте live‑Linux, увімкніть IOMMU/VT‑d і Above 4G у BIOS, потім виконайте дамп IOMMU груп (Завдання 4). Якщо ваш цільовий пристрій приклеєний до критичних для хоста пристроїв — повертайте плату, поки можете.

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

1. Перелічіть пристрої для passthrough і вирішіть, які мають бути підключені до CPU.
2. Складіть шорт‑ліст плат, що документують проводку ліній і мають IOMMU + Above 4G + bifurcation у BIOS.
3. Тестуйте на столі точну конфігурацію (включно з заповненими M.2 слотами) і зафіксуйте IOMMU групи.
4. Відмовтеся від крихких рішень: якщо для роботи потрібен ACS override, або явно прийміть ризик, або змініть апаратне забезпечення.
5. Зробіть процес відтворюваним: зафіксуйте версію BIOS/налаштування і збережіть вивід команд, що доводять правильну ізоляцію хоста.

Якщо хочете просте правило, яке витримає тиск: купуйте за топологією, а не за маркетингом. Чисті 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 або допоміжне скидання), замість того щоб перезавантажуватися і сподіватися.

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

Мапа міфів: що люди думають, що роблять таймінги

Розмова про таймінги ОЗП зазвичай починається зі скріншота: «CL30! Це швидко.» Потім це миттєво перетворюється на обґрунтування покупки. Ось міфи, що марнують гроші і час.

Міф 1: «Нижчий CAS-затримка завжди робить усе швидшим»

Нижчий CAS (tCL) може зменшити затримку першого слова при доступі до DRAM. Це не те саме, що робити службу швидшою. Більшість реальних навантажень — суміш кеш-хітів, кеш-місів, паралелізму на рівні пам’яті, предфетчингу та очікування на інші речі (локи, сховище, мережа, планувальник). Щільні таймінги можуть допомогти навантаженню, яке послідовно обмежене латентністю пам’яті при випадкових зверненнях і поганій локальності. Це рідше, ніж стверджує маркетинг.

Міф 2: «Якщо моя пам’ять сертифікована на 6000 MT/s, значить я працюю на 6000»

У серверах часто це не так. Пам’ять знижується в частоті при більшій кількості DIMM на канал, змішаних ранках або залежно від конкретного SKU CPU. На десктопах ви можете навіть не використовувати профіль, за який заплатили. «Rated» — це можливість за певних умов, а не гарантія у вашому шасі.

Міф 3: «Таймінги — незалежні ручки керування»

Таймінги — це зв’язка обмежень. Змінюючи один, контролер пам’яті (або профіль XMP/EXPO) змінює інші, щоб залишитися стабільним. Ви можете «покращити CL», одночасно погіршивши tRFC, або підвищивши командний інтервал, або змусивши режим шестерні (gear) працювати інакше, що підвищить ефективну латентність. Чистий ефект може бути нейтральним або негативним.

Міф 4: «Пропускна здатність не важлива, якщо латентність низька»

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

Міф 5: «Ігрові комплекти пам’яті хороші для серверів, бо вони швидші»

Серверам потрібні стабільність, передбачувана продуктивність під навантаженням і підтримуваність. Це часто означає ECC, валідовані DIMM, консервативні таймінги і налаштування BIOS, які можна відтворити. «Швидке», що падає раз у два тижні, не є швидким. Це виклик на пейджер.

Жарт №1: Купувати ультранизьколатентну пам’ять, щоб прискорити сервіс, прив’язаний до сховища, це як поставити гоночні шини на навантажувач. Він все одно перевозить піддони.

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

1. SDRAM замінила асинхронну DRAM, бо синхронізація пам’яті з тактом дозволила вищу пропускну здатність; таймінги стали «видимими в маркетингу» близько ери PC133.
2. DDR (double data rate) передає дані по обох фронтах такту, тож «MT/s» (transfer/sec) стало реальним показником — але багато хто досі цитує MHz, ніби це те саме.
3. CAS-затримка вимірюється в циклах, а не в часі. CL16 на 3200 MT/s не обов’язково «гірше», ніж CL30 на 6000 MT/s; наносекунди можуть бути схожими.
4. tRFC (час циклу оновлення) став болючішим із DIMM високої щільності; великі DIMM можуть давати штрафи за оновлення, які проявляються як періодичні стрибки латентності.
5. Інтегровані контролери пам’яті (поширені з кінця 2000-х у x86) перемістили багато «поведінки пам’яті» з чипсету в CPU; BIOS і покоління CPU важать більше, ніж думають.
6. NUMA давно став стандартом в мульти-сокетних системах, і «локальна проти віддаленої пам’яті» може перевершити різницю між типовими бінками таймінгів.
7. Репутація ECC постраждала, бо споживчі платформи часто її приховували; у серверах вона буденна й всюди, і вартість її впливу зазвичай не там, де ви думаєте.
8. DDR5 ввела PMIC на модулі та інші структури bank/group; ви можете побачити вищу пропускну здатність, але й іншу поведінку латентності порівняно з усталеними DDR4 платформами.
9. Rowhammer (широко обговорювався в середині 2010-х) підвищив обізнаність про помилки через вплив пам’яті; налаштування стабільності й міграції можуть змінювати продуктивність тонко.

Що таке таймінги ОЗП насправді (і чому їх неправильно інтерпретують)

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

CAS-затримка (tCL) — це не «затримка пам’яті» в цілому

CAS латентність — це кількість тактів між адресою колонки і доступністю даних після активації рядка. Це лише одна частина шляху. Повна історія включає активацію рядка (tRCD), пре-заряд (tRP), час активного рядка (tRAS), поведінку оновлення (tRFC) і планування команд.

Також, спостережувана системою затримка доступу до пам’яті включає:

• черги в контролері пам’яті,
• конфлікти банків,
• конкуренцію за канал,
• затримки проміжків «core-to-uncore» в інтерконекті,
• і можливо віддалені переходи NUMA.

Отже: ви можете купити «CL30» і не бачити руху p99 латентності, бо контролер пам’яті зайнятий, або ваше навантаження переважно — L3-хіти, або вас обмежує GC, або ви просто зв’язані з I/O.

Частота проти таймінгів: рахуйте в наносекундах, а не на відчуттях

Таймінги вимірюються в циклах. Час циклу залежить від частоти передачі даних пам’яті. Приблизний спосіб перетворити CL у наносекунди:

• Такт пам’яті (MHz) приблизно MT/s ÷ 2.
• Час циклу (нс) приблизно 1000 ÷ MHz.
• CAS-час (нс) = CL × час циклу.

Це спрощено, але достатньо, щоб припинити купувати нісенітницю.

Чому «щільні» таймінги можуть означати «повільніше» на практиці

Контролери пам’яті роблять компроміси. Профіль «щільних таймінгів» може примусити:

• командний інтервал 2T замість 1T,
• інші співвідношення gear mode (залежно від платформи),
• або зменшення запасів стабільності, що запускає retraining, WHEA-повідомлення чи виправлені ECC-помилки.

Будь-яке з цього може викликати переривчасті стопи або обробку помилок, що руйнує хвостову латентність. Оператори піклуються про хвости.

Ось фраза надійності, до якої я повертаюсь: «Надія — не стратегія.» (парафразована ідея, часто приписується Edsger W. Dijkstra у інженерних колах)

Що важить більше за «щільні» таймінги

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

1) Кількість каналів пам’яті та їх заповнення

Додавання пропускної здатності через більшу кількість каналів (і правильне їх заповнення) часто переважає заощадження кількох наносекунд першого доступу. CPU з 8 каналами, що працює з 1 DIMM на канал на трохи нижчій швидкості, може перевершити «швидкий комплект», який працює на менше каналів або з пониженою частотою через неправильне розміщення.

Інакше кажучи: якщо ви купили найкрутіші DIMM і встановили їх так, що CPU використовує лише половину своїх каналів, ви побудували дорогую односмугову трасу.

2) Запас ємності

Не гламурно, але жорстко ефективно. Якщо ваша машина підміняє сторінки, робить активну рекламацію, агресивно стискає пам’ять або працює при високому тиску пам’яті, жодне покращення таймінгів вас не врятує. Більше RAM (або розумніше використання пам’яті) перемагає «CL-блиск» щоразу.

3) Локальність NUMA

У мульти-сокетних системах віддалений доступ до пам’яті може додавати більше латентності, ніж різниця між типовими DDR4/DDR5 таймінгами. Якщо потоки бази даних бігають між сокетами, продуктивність буде залежати від настрою планувальника. Виправлення розміщення NUMA і політики пам’яті зазвичай приносить більше користі, ніж бутік DIMM.

4) Стабільність під сталим навантаженням

Продакшн — це не 60-секундне прогон. Це тиждень сталого теплового режиму, випадкові піки температури і непередбачені патерни навантаження. Оверклокнуті профілі пам’яті можуть «майже працювати» і все одно створювати рідкісні помилки, які неможливо відрізнити від багів у ПЗ.

5) Сховище й мережа: звичні підозрювані

Багато команд женуться за таймінгами пам’яті, поки справжня латентність у:

• IO wait від повільного або насиченого сховища,
• чергуванні в мережі,
• конкуренції за локи,
• паузах garbage collection або фрагментації аллокатора,
• або тиску планувальника ядра.

Налаштування пам’яті — вторинний крок, якщо ви не довели, що воно первинне.

Жарт №2: Якщо ваш сервер свапить, таймінги пам’яті — це по суті мотиваційний плакат для page cache.

Реалії платформ: сервери, робочі станції та «ігрова пам’ять»

Сервери: RDIMM/LRDIMM, ECC і тиранія схвалених постачальницьких списків

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

Робочі станції: іноді можна налаштувати, але валідируйте по-великому

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

Десктопи: XMP/EXPO — це зручність, а не контракт

XMP/EXPO — це заздалегідь налаштовані параметри оверклокінгу. Вони можуть бути нормальні для персональної машини, але щойно ви почнете використовувати цю машину для серйозної роботи — CI-білдерів, стейджинг-кластерів, edge-кешів — вам потрібен план валідації. Багато «таємничої» нестабільності походить від профілів пам’яті, що майже стабільні.

DDR4 проти DDR5: пастка — порівнювати неправильний показник

DDR5 часто дає вищу пропускну здатність, що чудово для навантажень із великим throughput. Але покращення першої затримки не гарантоване, особливо на ранніх платформах або з певними gear-співвідношеннями й поведінкою контролера. Не купуйте DDR5 в очікуванні універсальної латентної переваги. Купуйте її, якщо вам потрібні пропускна здатність, масштабування ємності або платформа з потрібними фічами.

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

Ви хочете знати, чи варто взагалі думати про таймінги ОЗП. Ось як швидко це з’ясувати, не перетворюючи на місячний перформанс-арт-проєкт.

Перше: доведіть, чи взагалі ви обмежені пам’яттю

• Перевірте завантаження CPU і чергу виконання: чи ви CPU-bound або застопорені?
• Перевірте тиск пам’яті і активність свапу: чи ОС бореться за пам’ять?
• Перевірте iowait: чи сховище — справжнє вузьке місце?

Друге: якщо пам’ять фігурує, вирішіть — це латентність чи пропускна здатність

• Латентні обмеження зазвичай показують високу кількість stall cycles, низьку завантаженість пропускної здатності, погану масштабованість за ядрами і чутливість до pointer-chasing навантажень.
• Обмеження пропускної здатності показує високу тривалу активність читань/записів, насичені канали і покращення throughput при додаванні каналів або вищих MT/s.

Третє: перевірте топологію і конфігурацію перед покупкою

• Всі канали пам’яті заповнені правильно?
• Випадково не працюєте ви на нижчій швидкості через кількість DIMM/ранків?
• Чи не зламана локальність NUMA?
• Чи є виправлені помилки пам’яті, що вказують на маргінальну стабільність?

Четверте: бенчмарк у спосіб, що нагадує вашу біль

• Спочатку використовуйте метрики на рівні застосунку (p95/p99 латентність, throughput, час GC, час запиту).
• Мікробенчмарки використовуйте лише для пояснення спостережуваних змін, а не для виправдання покупок.

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

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

Завдання 1: Підтвердьте ефективну швидкість пам’яті та заповнені слоти

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator:|Size:|Type:|Speed:|Configured Memory Speed:|Rank:'
Locator: DIMM_A1
Size: 32768 MB
Type: DDR4
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Rank: 2
Locator: DIMM_B1
Size: 32768 MB
Type: DDR4
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Rank: 2

Що це означає: Ваші DIMM можуть бути сертифіковані на 3200 MT/s, але налаштовані на 2933 MT/s. Це не баг; часто це — правила платформи.

Рішення: Якщо вам потрібна пропускна здатність, перевірте гайд по заповненню слотів платформи та обмеження SKU CPU перед покупкою «швидших» DIMM. Можливо, вас обмежує кількість DIMM на канал або число ранків, а не комплект.

Завдання 2: Перевірте конфігурацію каналів (швидкий погляд)

cr0x@server:~$ sudo lshw -class memory -short
H/W path     Device  Class          Description
/0/1                 memory         256GiB System Memory
/0/1/0               memory         32GiB DIMM DDR4 2933MT/s
/0/1/1               memory         32GiB DIMM DDR4 2933MT/s
/0/1/2               memory         32GiB DIMM DDR4 2933MT/s
/0/1/3               memory         32GiB DIMM DDR4 2933MT/s
/0/1/4               memory         32GiB DIMM DDR4 2933MT/s
/0/1/5               memory         32GiB DIMM DDR4 2933MT/s
/0/1/6               memory         32GiB DIMM DDR4 2933MT/s
/0/1/7               memory         32GiB DIMM DDR4 2933MT/s

Що це означає: У вас встановлено багато DIMM; це добре, але це не підтверджує правильне відображення на канали.

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

Завдання 3: Подивіться топологію NUMA

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 128000 MB
node 0 free: 42000 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 128000 MB
node 1 free: 12000 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Що це означає: Віддалена пам’ять приблизно в 2× «відстані» проти локальної. Якщо ваш процес виділяє на node 0, а виконується на node 1, латентність погіршується автоматично.

Рішення: Виправте афінність CPU/пам’яті для чутливих до латентності сервісів перед покупкою інших DIMM.

Завдання 4: Перевірте, чи використовуєте свап

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       228Gi       3.2Gi       1.1Gi        20Gi        11Gi
Swap:           16Gi       7.8Gi       8.2Gi

Що це означає: Активне використання swap. Ваша латентність уже вогненна; таймінги пам’яті — не перший хід.

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

Завдання 5: Спостерігайте за активністю пагінгу з часом

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0 8123456 3328120  9120 18341000  20  55   120   340 8200 9900 62 11 20  7  0
 5  0 8125520 3289040  9120 18350000  18  49   110   360 8100 9800 63 12 19  6  0

Що це означає: Ненульові si/so вказують на свап ін/аут. Навіть невеликий стійкий свап може знищити хвостову латентність.

Рішення: Розглядайте це як проблему ємності/SLO в першу чергу. Таймінги — потім, якщо взагалі.

Завдання 6: Перевірте, чи ви обмежені I/O wait

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.11    0.00    8.40   38.70    0.00   30.79

Device            r/s     w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1         820.0   210.0  96000   18000  12.30    7.20  98.50

Що це означає: Ваш CPU чекає на сховище; NVMe працює на високому навантаженні.

Рішення: Не купуйте низьколатентну пам’ять. Виправляйте сховище: додайте пристроїв, покращіть чергування, налаштуйте файлову систему, оптимізуйте кешування або зменшіть I/O-ампліфікацію.

Завдання 7: Перевірте лічильники пропускної здатності пам’яті (приклад Intel через perf)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,stalled-cycles-frontend,stalled-cycles-backend sleep 5
 Performance counter stats for 'system wide':

   18,220,443,901,120      cycles
    9,110,128,774,321      instructions              #    0.50  insn per cycle
        902,112,004      cache-misses
    6,300,110,221,900      stalled-cycles-frontend
    7,802,993,110,440      stalled-cycles-backend

       5.001234567 seconds time elapsed

Що це означає: Низький IPC і багато stalled cycles натякають, що CPU чекає — це може бути пам’ять, а може бути branch mispredict, I/O або локи.

Рішення: Корелюйте з іншими сигналами (iowait, run queue, NUMA, perf top). Не робіть висновку «стани = купити RAM» без перевірки.

Завдання 8: Визначте топ споживачів латентності в ядрі/юзерспейсі

cr0x@server:~$ sudo perf top -a
Samples: 36K of event 'cycles', 4000 Hz, Event count (approx.): 9123456789
Overhead  Shared Object        Symbol
  18.21%  mysqld               [.] btr_search_build_key
  11.04%  libc.so.6            [.] __memmove_avx_unaligned_erms
   9.66%  vmlinux              [k] copy_page_rep
   7.12%  vmlinux              [k] do_page_fault

Що це означає: Значна частина часу в memmove/copy і шляхах page fault. Це може вказувати на тиск пам’яті, неефективні копії або погану локальність.

Рішення: Якщо page fault високі — виправляйте тиск пам’яті і налаштування перш ніж купувати швидку пам’ять. Якщо копії домінують — розгляньте зміни в ПЗ (пакетування, zero-copy, налаштування компресії) перед шопінгом таймінгів.

Завдання 9: Перевірте transparent huge pages і використання hugepage (поширена причина латентності)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Що це означає: THP встановлено в always. Деякі бази даних та сервіси, чутливі до латентності, не люблять несподівані паузи через компактну дефрагментацію.

Рішення: Для баз даних, критичних за латентністю, розгляньте перехід на madvise або never згідно з рекомендаціями вендора і тестуванням. Це часто краще за незначні різниці таймінгів.

Завдання 10: Перевірте наявність виправлених помилок пам’яті (ECC) або machine check логів

cr0x@server:~$ sudo journalctl -k | egrep -i 'mce|edac|ecc|machine check' | tail -n 5
Jan 12 10:11:22 server kernel: EDAC MC0: 1 CE on DIMM_A1 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)
Jan 12 10:11:22 server kernel: mce: [Hardware Error]: Corrected error, no action required.

Що це означає: Логуються виправлені ECC-помилки (CE). Це тривожний знак: система виживає, але ви можете бути на межі.

Рішення: Не затягуйте таймінги і не вмикайте агресивні профілі пам’яті. Дослідіть стан DIMM, сидіння в слоті, тепловий режим і розгляньте заміну. Надійність важить більше, ніж маргінальна швидкість.

Завдання 11: Підтвердіть нинішній режим керування частотою CPU і scaling (часто помилково зв’язують з RAM)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Що це означає: У вас powersave. Ваша «апгрейд пам’яті» — не причина повільності сервісу; CPU економить енергію.

Рішення: Для вузлів, критичних за продуктивністю, переключіться на performance (з урахуванням тепла/потужності) і перезміряйте перед змінами апаратного забезпечення.

Завдання 12: Перевірте тиск пам’яті і stalls при reclaim (PSI)

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.42 avg60=0.38 avg300=0.21 total=123456789
full avg10=0.08 avg60=0.05 avg300=0.02 total=23456789

Що це означає: Існує тиск пам’яті; full вказує на періоди, коли задачі зупиняються в очікуванні пам’яті.

Рішення: Додайте запас ємності, налаштуйте ліміти cgroup або виправте витоки пам’яті перед дебатами про таймінги.

Завдання 13: Підтвердіть фактичну частоту DRAM (коли вона видно) та підсумок топології

cr0x@server:~$ sudo lscpu | egrep -i 'Model name|Socket|Thread|Core|NUMA|L3 cache'
Model name:                           Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
Socket(s):                            2
Core(s) per socket:                   16
Thread(s) per core:                   2
NUMA node(s):                         2
L3 cache:                             24 MiB (2 instances)

Що це означає: Ви на двосокетній NUMA-системі з відносно скромним L3 на сокет. Це важливо: локальність і дисципліна пропускної здатності ключові.

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

Завдання 14: Виміряйте зміну, видиму для застосунку, а не синтетичні перемоги

cr0x@server:~$ sudo awk '{print $1}' /var/log/nginx/access.log | tail -n 5
0.124
0.091
0.310
0.087
0.452

Що це означає: Реальні латентності запитів варіюються; ваша ціль — покращення p95/p99 під навантаженням, а не зниження числа в мікробенчмарку.

Рішення: Якщо зміни в пам’яті не впливають на хвости латентності істотно (і повторювано), припиніть. Інвестуйте в ємність, топологію або I/O.

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

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

Налаштування: чутливий до латентності API, що багато працював в пам’яті — кешування, парсинг JSON і трохи звернень до бази. Команда іноді бачила стрибки p99 і вирішила, що винна латентність пам’яті. Хтось запропонував «преміум» низьколатентні DIMM і BIOS-профіль із жорсткішими таймінгами.

Їх встановили на вікні змін у вихідні. Мікробенчмарки показали відмінні результати. Команда оголосила перемогу і пішла далі. У понеділок ранком перший стрибок був ще гірший. Потім інший. Потім відбулася аварія, що виглядала як софтверний дедлок.

Корінь проблеми не був у застосунку: профіль пам’яті був маргінальним під тривалим тепловим навантаженням. Машина почала логувати виправлені ECC-помилки. Виправлені помилки «припустимі», доки раптом не стають неприйнятними — бо система витрачає час на їх обробку, і вони можуть бути канаркою DIMM, що згодом видасть невиправлені помилки. Стрибки латентності співпали з хвилями помилок і retraining.

Вони відкотилися до JEDEC-таймінгів і замінили один DIMM, який став постійним порушником. Сервіс стабілізувався. Неприємний урок: хибне припущення було в думці, що нижчі таймінги = нижча латентність = кращий продакшн. Продакшн цінував передбачуваність. Пам’ять цінувала фізику.

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

Інша компанія, інша проблема: велика аналітична робота на парку двосокетних серверів. Команда була сфокусована на throughput. Вони купили пам’ять з вищим MT/s, очікуючи лінійні виграші. Під час розгортання вони також збільшили щільність DIMM, щоб зменшити кількість слотів і спростити запаси.

Продуктивність погіршилася. Не трохи — настільки, що звинувачували софтверну команду. Зміна була пов’язана з новою пам’яттю, бо вона була найпомітнішою. Вони вже планували повернення товару.

Насправді проблема була в правилах ранків і заповненні. Переходячи на менше, але більш щільні DIMM, вони опинилися з меншою кількістю DIMM на сокет і випадково зменшили активні канали на частині флоту через помилки розміщення слотів. На додачу контролер пам’яті понизив частоту через конфігурацію DIMM. Вони купили «швидшу» пам’ять, але налаштували платформу так, щоб вона працювала повільніше й уже вужче.

Після виправлення заповнення слотів (і погодження трохи нижчого MT/s за умови повного використання каналів) throughput підскочив вище за початкову базу. Проблема не в RAM як такій. Вона в тому, що підсистема пам’яті — це топологія, а не кошик покупок: «дорожче = швидше» не працює.

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

Фінтех-команда тримала кластер бази даних, який був алергічний до хвостової латентності. Їх практика була болісно нудною: для кожного покоління апаратного забезпечення вони мали стандартний BIOS-профіль, стандартний BOM DIMM і стандартний прогін burn-in, що включав стрес пам’яті та парсинг логів на предмет ECC чи machine check подій.

Під час планового масштабування один вузол показав кілька виправлених помилок під час burn-in. Постачальник пропонував махнути рукою — «corrected, no action required». Команда наполягла на заміні DIMM перш ніж вузол зайняв виробничий трафік.

Через тижні інша команда в тій самій компанії ігнорувала схожі попередження на менш критичному сервісі. Та машина згодом почала викидати невиправлені помилки під піком і перезавантажилася несподівано. Фінтех-кластер? Спокійний. Нудний. Передбачуваний.

Що «врятувало день» — не була якась магічна пам’ять. Це була дисципліна: ставитись до виправлених помилок як до раннього попередження, а не як до фонової складової. У продакшні нудність — це функція.

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

1) Симптом: «Ми апгрейдили RAM, але нічого не змінилося»

Корінь проблеми: Навантаження не обмежене пам’яттю, або система понизила частоту до налаштованої швидкості, або ви I/O-bound.

Виправлення: Виміряйте iowait, свап, PSI і p99 застосунку. Підтвердьте налаштовану швидкість пам’яті через dmidecode. Лише після цього розглядайте зміну пам’яті.

2) Симптом: «Випадкові p99 стрибки після вмикання XMP/EXPO»

Корінь проблеми: Маргінальна стабільність: виправлені ECC-помилки, WHEA-події, retraining або теплова чутливість.

Виправлення: Поверніться до JEDEC-таймінгів. Проведіть burn-in. Перевірте логи ядра на EDAC/MCE. Замініть сумнівні DIMM; не запускайте продакшн на «майже стабільному» обладнанні.

3) Симптом: «Throughput погіршився після переходу на DIMM вищої щільності»

Корінь проблеми: Зменшена використаність каналів, більше ранків, або правила платформи змусили понизити швидкість.

Виправлення: Дотримуйтеся гіда по заповненню слотів платформи. Для навантажень, чутливих до пропускної здатності, віддавайте перевагу 1 DIMM на канал, коли можливо.

4) Симптом: «Двосокетна машина поводиться непослідовно між прогоном і прогоном»

Корінь проблеми: NUMA-локальність: потоки і виділення пам’яті на різних вузлах.

Виправлення: Прикріпіть процеси/потоки, використовуйте NUMA-aware алокатори або політики, перевіряйте за numastat/numactl. Розгляньте односокетні дизайни для суворих SLO по латентності.

5) Симптом: «CPU виглядає завантаженим, але IPC низький»

Корінь проблеми: Stalls від пам’яті, branch mispredicts, конкуренція за локс або page fault.

Виправлення: Використовуйте perf для ідентифікації джерел stall. Якщо домінують page fault або reclaim — спочатку вирішіть тиск пам’яті.

6) Симптом: «Періодичні стриби латентності кожні кілька секунд»

Корінь проблеми: Поведінка оновлення (вплив tRFC), throttling пам’яті, THP-компакція або фонова технічна задача.

Виправлення: Корелюйте з логами ядра і перформанс-лічильниками. Налаштуйте THP, перевірте термічний режим і переконайтеся, що DIMM не тригерять тротлінг.

7) Симптом: «Продуктивність хосту VM нерівномірна між гостьовими ОС»

Корінь проблеми: Overcommit, що викликає reclaim на хості, NUMA-дисбаланс або гості, що охоплюють кілька вузлів.

Виправлення: Налаштуйте overcommit хоста, закріпіть vCPU, забезпечте локальність пам’яті і уникайте ballooning для сервісів, чутливих до латентності.

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

План прийняття рішення для покупки пам’яті (без марнотратства)

1. Запишіть проблему в вимірюваних термінах. Приклад: «p99 API латентність зростає з 180ms до 600ms під піком.» Якщо не можете це виміряти — не зможете вирішити купівлею.
2. Виключіть очевидні не-RAM вузькі місця. Спочатку перевірте iowait, свап, CPU governor і точки насичення.
3. Підтвердіть поточну ефективну конфігурацію пам’яті. Використайте dmidecode: дивіться налаштовану швидкість, ранки і загальну популяцію.
4. Валідуйте використання каналів. Переконайтеся, що ви використовуєте всі канали, які пропонує CPU. Виправляйте розміщення слотів перед покупкою.
5. Оцініть ризик NUMA. Якщо мульти-сокет, заплануйте афінність і політику пам’яті як частину розгортання, а не як післядію.
6. Спочатку ємність, потім пропускна здатність, потім таймінги. Ємність запобігає свапу. Пропускна здатність покращує throughput, коли канали завантажені. Таймінги — десерт, а не страва.
7. Віддавайте перевагу стабільним бінкам і ECC для продакшн-систем. Особливо для систем, що повинні давати правильний результат (БД, сховища, фінансові розрахунки).
8. Тестуйте як продакшн. Burn-in під тривалим навантаженням; збирайте логи на EDAC/MCE; запускайте репрезентативні тести трафіку; порівнюйте p95/p99.
9. Полегшіть відкат. Профілі BIOS з версіями; автоматизація для встановлення відомо-робочих конфігурацій; моніторинг для раннього виявлення виправлених помилок.

План налаштування, коли підозрюєте латентність пам’яті

1. Підтвердіть, що це не пагінг. Якщо так — зупиніться й виправте це.
2. Виправте NUMA-розміщення. Прикріпіть, поміряйте знову. Це часто дає більший ефект, ніж будь-яка зміна таймінгів.
3. Перевірте THP і поведінку компакції. Особливо для БД і JVM-навантажень.
4. Вимірюйте зміни на рівні застосунку. Якщо p99 не змінюється, не продовжуйте крутити ручки.
5. Лише потім експериментуйте з налаштуваннями пам’яті. Один крок за раз; тестуйте; слідкуйте за логами помилок; тримайте стабільну базу.

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

1) Чи важлива латентність пам’яті для серверів?

Іноді. Це найважливіше для чутливих до латентності, pointer-chasing навантажень із поганою локальністю (деякі in-memory бази, графові навантаження, трейдингові системи). Для багатьох сервісів топологія (канали, NUMA) і запас ємності більш важливі.

2) Чи CAS-затримка — основний показник для порівняння?

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

3) DDR5 швидша, тож чи зменшить вона p99 латентність?

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

4) Чи вмикати XMP/EXPO на продакшн-машинах?

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

5) Чи сповільнює ECC пам’ять?

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

6) Яка найбільша RAM-помилка, що її ви бачите?

Неправильна або неповна популяція каналів. Люди купують швидкі DIMM і випадково запускають систему з половиною доступної пропускної здатності. Це поширено і цілком уникнути можливо.

7) Як зрозуміти, що я обмежений пропускною здатністю?

Ви побачите високу стійку активність пам’яті, throughput, що масштабується з каналами/MT/s, і покращення продуктивності при розподілі роботи по сокетах з локальною пам’яттю. Використовуйте perf-лічильники та корелюйте з характеристиками навантаження (streaming scans, compression, analytics).

8) Як зрозуміти, що я обмежений латентністю?

Зазвичай ви побачите низький IPC, багато stalled cycles і чутливість до розміщення потоків і поведінки кешу. Профілювання застосунку покаже час у pointer-heavy шляхах. Покращення дадуть локальність, зменшення індирекцій та дисципліна NUMA — а не лише жорсткі таймінги.

9) Для ZFS або серверів зберігання, чи варто купувати низьколатентну пам’ять?

Зазвичай спочатку потрібні ємність і надійність. Розмір ARC і кеш метаданих важливі. Якщо ви I/O-bound на дисках/NVMe або мережі, таймінги не допоможуть. Також: сервери зберігання — останнє місце, де хочете маргінальну стабільність пам’яті.

10) Коли розумно платити більше за кращі таймінги?

Коли ви виміряли повторюваний, видимий на рівні застосунку приріст під репрезентативним навантаженням і можете зберегти стабільність. Якщо ви не можете показати покращення p95/p99 або throughput, яке впливає на вартість, не робіть цього.

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

1. Аудит флоту на предмет «rated vs configured» швидкості пам’яті. Зберіть вивід dmidecode і порівняйте між апаратними SKU. Знайдіть випадкові downclock і дивні змішані популяції.
2. Перевірте логи на наявність виправлених помилок. Якщо бачите EDAC/MCE-повідомлення, зупиніть налаштування і почніть заміну. Виправлені помилки — не риса характеру.
3. Виберіть одне репрезентативне навантаження і виміряйте правильно. Відстежуйте p95/p99, throughput, завантаження CPU, iowait, swap і PSI під навантаженням. Зробіть просту таблицю до/після.
4. Виправте популяцію каналів і NUMA-розміщення перш за все. Це структурні речі. Вони дають великі, надійні виграші і зменшують варіативність.
5. Лише потім розглядайте зміни швидкості/таймінгів пам’яті. Якщо змінюєте — тримайте план відкату і вважайте стабільність першочерговою метрикою.

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

Ментальна модель: що таке IOMMU‑група насправді

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

Чому «IOMMU увімкнено» — не та перемога, яку ви думаєте

Увімкнення IOMMU (Intel VT‑d / AMD‑Vi) дає платформі здатність транслювати та обмежувати DMA. Це не гарантує, що кожен PCIe‑ендпоінт отримає свій окремий чистий сандбокс. Ізоляція залежить від ланцюга довіри між ендпоінтом і CPU: root port, будь‑які низхідні порти, PCIe‑комутатори та наявність відповідних Access Control Services (ACS) і пов’язаних керувань на цьому шляху.

Межа групи зазвичай відповідає межі моста

На практиці межі IOMMU‑груп часто збігаються з PCIe‑мостами/портами, які можуть забезпечити розділення. Якщо у вас є один низхідний порт, що живить кілька ендпоінтів (або комутатор, який не оголошує чи не вмикає ACS належним чином), Linux може об’єднати їх. Це не тому, що Linux злий. Це тому, що Linux відмовляється обіцяти ізоляцію, яку він не може довести.

Перефразована ідея від James Hamilton (Amazon): «Вимірюй усе, не припускай нічого». Вона болісно добре підходить до IOMMU‑груп — припущення про топологію призводять до того, що ви виведете USB‑контролер разом із GPU.

Швидкий план діагностики (що перевірити насамперед)

Перше: підтвердіть, що IOMMU дійсно активний, а не просто «налаштований»

• Перевірте dmesg на наявність рядків про DMAR/AMD‑Vi та статус ремапінгу.
• Переконайтеся, що IOMMU‑групи існують у /sys/kernel/iommu_groups.

Друге: ідентифікуйте конкретні пристрої, які вас цікавлять, і їхній шлях вверх по шині

• Зіставте GPU/HBA/NIC до PCI‑адрес за допомогою lspci -nn.
• Пройдьте дерево PCIe з lspci -tv і lspci -vv.
• Знайдіть upstream‑міст і чи присутній/увімкнений на ньому ACS.

Третє: вирішіть, чи це можна виправити апаратно/прошивкою або лише «виправити» через оверрайди

• Якщо пристрої ділять групу через те, що вони під’єднані за одним низхідним портом без ACS: змініть слот, увімкніть BIOS‑опції або змініть платформу.
• Якщо пристрої ділять групу тому, що виробник материнської плати провів кілька слотів за одним root‑портом: прийміть реальність, переробіть дизайн або використайте ACS override, усвідомлюючи компроміси.

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

Факти й історія, що пояснюють сучасний безлад

1. VT‑d і AMD‑Vi з’явилися значно пізніше за CPU‑віртуалізацію. Рання віртуалізація зосереджувалася на рівнях привілеїв CPU; ізоляція DMA прийшла пізніше і поволі прогресувала в чіпсетах.
2. PCIe ACS — опціональна можливість. ACS — це здатність, яку пристрої/порти можуть або не можуть реалізувати. Опціональні функції — це місце, де мрії вмирають.
3. IOMMU‑групи — це політика Linux поверх апаратних реалій. Ядро формує групи на основі гарантій ізоляції; це не «функція passthrough», а межа безпеки.
4. Багато споживчих материнських плат оптимізують лінії, а не ізоляцію. Розподіл x16 у x8/x8 через той самий root complex може бути нормальним для продуктивності, але жахливим для групування.
5. PCIe‑комутатори не є магічними боксами ізоляції. Деякі комутатори реалізують ACS добре; інші — ні, або прошивка залишає його відключеним. Те саме позначення деталі на різних платах дає різний результат.
6. Багатофункційні пристрої можуть бути нероздільними за дизайном. GPU з аудіо‑функцією зазвичай — один фізичний пристрій з кількома функціями; ці функції часто залишаються в одній IOMMU‑групі.
7. «ACS override» з’явився тому, що люди постійно просили. Ядро отримало регулятори для пом’якшення групування в випадках віртуалізації. Це практично, а не святе.
8. Thunderbolt і зовнішній PCIe добавляють додаткову топологічну складність. Мости гарячого підключення та рівні безпеки ускладнюють довіру до DMA і поведінку групування.
9. SR‑IOV змінив очікування. Після того як мережеві карти почали надавати багато VFs, всі очікували охайної ізоляції — і виявили, що платформа все ще вирішує групи.

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

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

Завдання 1: Підтвердити, що ядро бачить активний IOMMU (Intel)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU"
[    0.012345] DMAR: IOMMU enabled
[    0.012678] DMAR: Host address width 39
[    0.013210] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.015432] DMAR: Intel(R) Virtualization Technology for Directed I/O

Значення: рядок «IOMMU enabled» — те, чого ви шукаєте. Якщо ви бачите лише таблиці DMAR, але без увімкнення, реального ремапінгу DMA немає.

Рішення: Якщо відсутній, виправте BIOS (VT‑d) і параметри ядра (intel_iommu=on) перш ніж витрачати час на групи.

Завдання 2: Підтвердити, що ядро бачить активний IOMMU (AMD)

cr0x@server:~$ dmesg | grep -E "AMD-Vi|IOMMU"
[    0.010101] AMD-Vi: IOMMU performance counters supported
[    0.010202] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.010303] AMD-Vi: Interrupt remapping enabled

Значення: наявність AMD‑Vi і ввімкненого ремапінгу переривань — хороший знак для безпечного делегування пристрою.

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

Завдання 3: Перевірити наявність IOMMU‑груп

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
2
3
4
5
6
7
8
9

Значення: Групи існують. Якщо директорія порожня або відсутня, у вас немає активного групування IOMMU.

Рішення: Відсутність груп означає зупинитися й виправити увімкнення (BIOS/ядро). Групи є — перейдіть до топології.

Завдання 4: Вивести групи з іменами пристроїв (швидкий інвентар)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; for d in $g/devices/*; do lspci -nns ${d##*/}; done; echo; done | sed -n '1,35p'
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1234]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678]

Group 1
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a36d]
00:14.2 RAM memory [0500]: Intel Corporation Device [8086:a36f]

Group 2
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:228b]

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

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

Завдання 5: Ідентифікувати пристрій і драйвер ядра (хто ним володіє)

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

Значення: Якщо пристрій прив’язаний до драйвера хоста, VFIO‑passthrough буде конфліктувати під час завантаження або старту VM.

Рішення: Прив’язуйте до vfio-pci (або stub) тільки після підтвердження, що група прийнятна. Не «виправляйте» групування переназначенням драйверів — це не допоможе.

Завдання 6: Показати топологію PCIe як дерево (знайти батьківський міст)

cr0x@server:~$ lspci -tv
-+-[0000:00]-+-00.0  Host bridge
 |           +-01.0-[01]----00.0  VGA compatible controller
 |           |            \-00.1  Audio device
 |           +-14.0  USB controller
 |           +-17.0  SATA controller
 |           \-1d.0-[02]----00.0  Ethernet controller

Значення: Ваш GPU знаходиться за 00:01.0. Якщо кілька ендпоінтів знаходяться під тим самим низхідним сегментом і згруповані — upstream‑порт, ймовірно, не ізолює.

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

Завдання 7: Перевірити ACS‑можливості на upstream‑порті

cr0x@server:~$ sudo lspci -vv -s 00:01.0 | grep -A8 -i "Access Control Services"
	Access Control Services
		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-

Значення: Можливість існує, але керування може бути вимкненим. Деякі платформи залишають ACSCtl біти вимкненими.

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

Завдання 8: Перевірити режим трансляції платформи

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

Значення: intel_iommu=on вмикає ремапінг. iommu=pt встановлює passthrough для хостових пристроїв (часто покращує продуктивність для неделегованих пристроїв).

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

Завдання 9: Підтвердити стан ремапінгу переривань / posted interrupts

cr0x@server:~$ dmesg | grep -E "Interrupt Remapping|IR|x2apic" | head -n 20
[    0.013333] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.013444] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.

Значення: Ремапінг IRQ зменшує ймовірність доставляння переривань не туди при делегуванні.

Рішення: Якщо він вимкнений, вважайте passthrough більш ризикованим; для продукції пріоритезуйте оновлення прошивки або зміну платформи.

Завдання 10: Перевірити, чи GPU в групі з мостом, яким ви не керуєте

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

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

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

Завдання 11: Ідентифікувати, хто ще в групі (перевірка «хто ще в кімнаті»)

cr0x@server:~$ G=$(basename $(readlink /sys/bus/pci/devices/0000:01:00.0/iommu_group)); for d in /sys/kernel/iommu_groups/$G/devices/*; do lspci -nnk -s ${d##*/}; echo; done
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2484] (rev a1)
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb

01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:228b] (rev a1)
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Значення: GPU + його аудіо‑функція лише? Це зазвичай нормально. GPU + USB + SATA? Це конструкційне обмеження.

Рішення: Якщо бачите несумісні пристрої, вирішуйте між: перемістити карти/слоти, змінити BIOS‑настройки, вибрати іншу плату/CPU або застосувати ACS override (із ризиком).

Завдання 12: Перевірити наявність PCIe‑комутатора в шляху (часто в серверах, іноді в робочих станціях)

cr0x@server:~$ lspci -nn | grep -i "PCI bridge\|PLX\|Broadcom\|PEX"
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678]
03:00.0 PCI bridge [0604]: Broadcom / PLX Device [10b5:8725]
03:01.0 PCI bridge [0604]: Broadcom / PLX Device [10b5:8725]

Значення: Комутатори часто відображаються як кілька функцій мосту. Чи ізолюють вони — залежить від ACS та конфігурації.

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

Завдання 13: Підтвердити вигляд ізоляції через цілеспрямований ACS‑скан ядра

cr0x@server:~$ for dev in 00:01.0 03:00.0 03:01.0; do echo "== $dev =="; sudo lspci -vv -s $dev | grep -A6 -i "Access Control Services"; done
== 00:01.0 ==
	Access Control Services
		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
== 03:00.0 ==
	Access Control Services
		ACSCap: SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans-
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-

Значення: Можливості відрізняються на кожному порті. Деякі порти можуть робити перенаправлення запитів, але не контролювати upstream‑пересилання і т.д.

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

Завдання 14: Перевірити, чи платформа примусово використовує «Above 4G decoding» / вплив Resizable BAR

cr0x@server:~$ dmesg | grep -iE "Resizable BAR|Above 4G|pci 0000"
[    0.222222] pci 0000:01:00.0: BAR 0: assigned [mem 0x8000000000-0x800fffffff 64bit pref]
[    0.222333] pci 0000:01:00.0: BAR 2: assigned [mem 0x8010000000-0x8011ffffff 64bit pref]

Значення: Великі BAR‑мапінги не є проблемою групування, але можуть виявити баги прошивки та проблеми виділення ресурсів, які маскуються під проблеми VFIO.

Рішення: Якщо бачите помилки виділення ресурсів або відсутні BAR, виправте це перш за все; некоректна ініціалізація пристрою може змусити вас ганятися за фантомними «IOMMU‑проблемами».

Завдання 15: Підтвердити придатність VFIO без остаточної прив’язки (думка «сухого прогону»)

cr0x@server:~$ sudo dmesg | tail -n 20
[  120.123456] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  120.123789] vfio-pci 0000:01:00.0: vfio_bar_restore: reset recovery - restoring BARs
[  120.124111] vfio-pci 0000:01:00.1: enabling device (0000 -> 0002)

Значення: Коли ви прив’язуєте, ядро логує свої дії. Помилки тут часто вказують на особливості скидання, а не на групування.

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

Жарт #1: IOMMU‑група як бронювання конференц‑кімнати: якщо ваш USB‑контролер з’явився, усі вийдуть із маркерами з вашої дошки.

Клініка PCIe‑топології: root port, мости, комутатори і ACS

Починайте з upstream‑шляху, а не з ендпоінта

Люди захоплюються моделлю GPU і забувають про нудну частину: PCIe‑фабрику. Ваш ендпоінт можна ізолювати лише настільки, наскільки найслабший міст між ним і CPU це підтримує. До уваги входять:

• Root port / root complex на CPU або чіпсеті.
• Низхідні порти (часто частина комутатора або чіпсетної структури).
• PCIe‑комутатори (PLX/Broadcom, ASMedia і т. п.).
• Інтегровані ендпоінти (вбудоване аудіо, USB‑контролери, SATA, Wi‑Fi).

ACS: що воно робить і чому змінює групування

Access Control Services — набір функцій, що допомагають запобігти або контролювати peer‑to‑peer трафік і забезпечують коректне маршрутування запитів вгору, де IOMMU може застосувати політику. Простими словами: ACS допомагає зупинити пристрої за одним комутатором/портом від прямого обміну між собою поза контролем IOMMU.

Linux використовує інформацію про ACS (та інші підказки топології), щоб вирішувати, чи можна розділити пристрої на різні IOMMU‑групи. Якщо платформа не може гарантувати ізоляцію, група лишається великою.

Типові патерни «чому мій GPU згрупований з X?»

• Низхідний порт чіпсета з фанов‑аулайном: кілька вбудованих контролерів під’єднані за одним портом чіпсета без ACS — тому їх групують.
• Спільний комутатор: два фізичні слоти фактично під одним PCIe‑комутатором без правильної ACS‑конфігурації.
• Мультиплексування ліній на материнській платі: увімкнення другого слота M.2 перенаправляє лінії і змінює, які пристрої ділять root‑порт.
• Багатофункційні пристрої: GPU video + GPU audio ділять групу. Це нормально і зазвичай бажано для passthrough.

Що насправді означає «виправити топологію»

Це не містика. Це одне з таких рішень:

1. Перемістити карту в інший слот, що підключений до іншого root‑порту (найкраще — прикріпленого до CPU).
2. Не використовувати слот/M.2, що змушує спільне використання ліній з тим, що потрібно ізолювати.
3. Увімкнути опції прошивки, що показують ACS або коректний ремапінг (коли вони доступні).
4. Використати апарат, що справді підтримує ізоляцію: робочі/серверні плати, перевірені комутатори, CPU з достатньою кількістю ліній.
5. Прийняти групування і передати всю групу, якщо це безпечно і прийнятно операційно.

Більшість «проблем з IOMMU‑групами» — це ваша материнська плата, яка тихо каже, що вона розроблена для ігрового RGB, а не для надійних DMA‑меж.

BIOS/прошивка: налаштування, що мають значення (і ті, що ні)

Налаштування, які зазвичай важливі

• Intel: VT‑d (Directed I/O) має бути увімкнено. Тільки VT‑x — недостатньо.
• AMD: SVM увімкнює віртуалізацію CPU; IOMMU (або «AMD‑Vi») вмикає ремапінг DMA. Зазвичай потрібні обидва для passthrough.
• Above 4G decoding: часто потрібне для сучасних GPU і кількох PCIe‑пристроїв; також впливає на розподіл ресурсів прошивкою.
• SR‑IOV: увімкнення може змінити конфігурацію downstream‑портів і ARI; не обов’язково для passthrough, але важливо для VF NIC.
• Параметри PCIe ACS / «PCIe ARI»: якщо BIOS має опції, схожі на ACS, увімкніть їх. Якщо є ARI — увімкніть його при інтенсивному використанні SR‑IOV.

Налаштування, які люди переключають з відчаю

• CSM (Compatibility Support Module): вимкнення може допомогти ініціалізації сучасних GPU і розмірам BAR, але не розділить IOMMU‑групи.
• Примусова швидкість PCIe Gen: іноді допомагає стабільності лінку; рідко впливає на групування.
• «Gaming mode»: якщо такий режим є — відійдіть повільно.

Оновлення прошивки: непривабливе, але ефективне

Оновлення BIOS материнської плати та BMC/UEFI серверів може змінити експозицію ACS, пом’якшити проблеми ремапінгу та змінити розподіл ресурсів PCIe. Це не весело. Але це різниця між «працює місяцями» та «рандомним DMA‑фаултом о 3‑й ранку».

Параметри ядра, ACS override і коли їх не використовувати

Параметри, які ви побачите в природі

• intel_iommu=on / amd_iommu=on: явне увімкнення.
• iommu=pt: passthrough‑режим для хост‑пристроїв (компроміс продуктивність/латентність).
• pcie_acs_override=downstream,multifunction: змушує ядро трактувати деякі порти так, ніби ACS‑розділення існує.

Що насправді робить ACS override

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

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

Коли я використаю ACS override

• У лабораторіях, де єдиний «зловмисник» — моя власна нетерплячість.
• Для тимчасової валідації на платформі, яку ми вже плануємо замінити, щоб довести працездатність навантаження.
• Коли passthrough‑пристрій — єдиний значущий DMA‑ендпоінт у групі, а решта практично інертні (рідко).

Коли я відмовлюся від ACS override

• У мульти-орендних середовищах.
• У будь‑яких випадках з вимогами відповідності щодо ізоляції.
• У системах, де спільна група містить сховище або мережу, від яких залежить робота хоста.

Жарт #2: ACS override — як повісити стрічку «Не заходити» на дверях без дверей. Вона дає відчуття безпеки, поки хтось не пройде через неї.

Особливості стеку віртуалізації: Proxmox/KVM, bare metal та «корпоративні» системи

Перевірка реальності KVM/VFIO

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

На практиці «потрібно передати лише GPU» означає, що група GPU має містити тільки функції GPU (і можливо USB‑контролер, якщо ви свідомо передаєте цілий контролер для введення).

Proxmox та подібні стеки

Proxmox полегшує перегляд груп і конфігурацію VFIO, але не може виправити материнську плату, яка «зварила» ваш слот GPU з тим самим низхідним портом, що й SATA‑контролер. Якщо Proxmox показує велетенську групу — повірте йому.

Робоча станція проти серверних плат

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

Примітка інженера зберігання: не діліться групами з HBA легковажно

Якщо група містить ваш HBA або NVMe‑контролер, який використовує хост, ви на один невдалий крок від передачі контролера сховища VM. Це не «налаштування продуктивності». Це рулетка з втратою даних.

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

1) Інцидент через неправильне припущення

Вони збирали невеликий внутрішній кластер GPU для прискорення збірок і деякого ML‑інференсу. Нічого екзотичного: KVM, VFIO, кілька середніх GPU і стандартизована материнська плата, бо закупівля любила «стандартизацію». Хтось перевірив IOMMU у BIOS і побачив DMAR у dmesg. Оголосили платформу «passthrough‑ready».

Перші два вузли працювали, бо GPU стояли в слотах, підключених прямо до root‑портів CPU. Третій вузол зібрали трохи інакше — та сама плата, але додали NVMe‑карта‑носій. Цей накопичувач змінив біфуркацію ліній і пересунув слот GPU за шляхом через чіпсетний комутатор. Ніхто не помітив, бо GPU все ще відображалися в lspci.

На тому вузлі GPU опинився в тій же IOMMU‑групі, що USB‑контролер і SATA‑контролер. Інженер, що конфігурував VFIO, припустив, що «групи — це лише Linux‑штука», і примусово застосував ACS override, щоб їх розділити. Система пройшла початкові тести. Через тиждень під час інтенсивного навантаження на збірки хост зазнав періодичних помилок SATA, і потім файлову систему перевели в режим лише для читання. Розслідування було непоказним: вони створили фальшиву межу ізоляції, і інтенсивний DMA від GPU корелював з дивною поведінкою хост‑I/O.

Виправлення було болісно буденним: перемістити GPU в інший слот, відключити опцію спільного використання ліній і стандартизувати збірку так, щоб у кожного вузла була одна й та сама PCIe‑топологія. Також заборонили ACS override у продукції без погодження. Справжній урок не в тому, що «ACS override зло». Він у тому, що «IOMMU увімкнено» — не те саме, що «досягнута ізоляція IOMMU», а дрейф топології — це баг на надійності.

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

Команда хотіла зменшити латентність для VM з високою пропускною здатністю пакетної обробки. Планували передати NIC і GPU для на‑літу інференсу. На хості також був швидкий NVMe для локального кешу. Хтось помітив, що NIC і NVMe в одній IOMMU‑групі на певній генерації платформи.

Замість зміни апаратури вони зробили «хитрий» крок: передали всю групу в VM, аргументуючи, що VM — це «реальне навантаження», а хост може завантажитися з дзеркального SATA DOM. На папері це знизило накладні витрати і уникнуло розділення груп. Навіть бенчмарки виглядали добре.

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

Оптимізація обернулася проти, коли в VM стався збій драйвера і вона перестала відповідати. Хост лишився «up», але втратив доступ до переданих пристроїв, включно з кеш‑NVMe. Моніторинг заволав, і вузол почав миготіти в сервісах. Повернулися до менш «ефективного» дизайну: розділили IOMMU‑групи, вибравши інше розташування слотів і платформу з більшою кількістю root‑портів, тримали критичне для хоста сховище поза будь‑якою passthrough‑групою. Продуктивність трохи впала. Аптайм значно виріс. Героїв ніхто не сумував.

3) Нудна, але правильна практика, що врятувала день

Інша організація працювала зі змішаними навантаженнями: деякі VM з NIC‑passthrough (SR‑IOV VFs), інші з повним passthrough пристроїв для спеціалізованих прискорювачів. Їх уже колись «спалили», тому була політика: для кожного SKU апаратури мався «манифест PCIe‑топології», закомічений у той же репозиторій, що й код провізії.

Коли прибув новий партія серверів, закупівельна команда підмінила «сумісну» ревізію материнської плати через проблеми з постачанням. Той самий сімейство CPU, той самий шасі, для неспеціаліста — все те саме. CI‑перевірка порівняла очікувані макети IOMMU‑груп з тими, що повідомив свіжезавантажений вузол. Вона відразу провалилася.

Замість виявлення проблеми в продукції після нічного оновлення ядра — вони помістили партію в карантин. Причина виявилася в іншій конфігурації PCIe‑комутатора на новій ревізії: слот прискорювача і вбудований RAID‑контролер тепер ділили низхідний порт без корисного ACS‑розділення. Постачальник міг надати прошивку для деяких плат, для інших — вирішення було в іншому райзері.

Практика була нудною: завантажити, зібрати lspci, зібрати мапінги груп, зробити diff з очікуваним, швидко фейлити. Це зекономило дні дебагу і запобігло повільному інциденту. Ось така «паперова робота» реально підвищує доступність системи — тому її ненавидять допоки вона не врятує.

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

1) «Я увімкнув IOMMU, але /sys/kernel/iommu_groups порожній»

Симптом: Немає записів у директорії груп, VFIO скаржиться, гайди радять «увімкніть IOMMU».

Корінь проблеми: VT‑d/AMD‑Vi вимкнено в BIOS, або параметри завантаження ядра не вмикають його, або ви в режимі прошивки, що ховає ремапінг.

Виправлення: Увімкніть VT‑d/AMD IOMMU у BIOS; додайте intel_iommu=on або amd_iommu=on; оновіть BIOS, якщо таблиці DMAR пошкоджені.

2) «Мій GPU ділить групу з USB/SATA/NIC на материнській платі»

Симптом: Група містить GPU плюс несумісні вбудовані контролери.

Корінь проблеми: Пристрої сидять за тим самим низхідним портом/комутатором без ACS‑ізоляції; проводка материнської плати оптимізована під розподіл ліній, а не під ізоляцію.

Виправлення: Перемістіть GPU в слот, підключений до CPU; відключіть функції спільного використання ліній; уникайте M.2/райзерів, що перенаправляють лінії; оберіть плату з кращим розподілом root‑портів.

3) «Я використав ACS override, і воно працює, але з’являються випадкові помилки I/O на хості»

Симптом: Passthrough працює, але хост отримує періодичні PCIe/SATA/NVMe неполадки під навантаженням.

Корінь проблеми: Примусове розбиття груп створило межу, яку апарат не підтримує; peer‑to‑peer та DMA‑взаємодії стали невизначеними.

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

4) «Проблеми зі скиданням GPU виглядають як проблеми IOMMU»

Симптом: Після вимкнення VM GPU стає непридатним, наступний запуск VM не вдається, в dmesg помилки про reset.

Корінь проблеми: Особливості скидання GPU (FLR може не підтримуватися), поведінка драйвера вендора або обробка багатофункційності — не групування IOMMU.

Виправлення: Використовуйте підтримувані вендором механізми скидання (де застосовно), розгляньте інші моделі GPU, переконайтеся, що обидві функції GPU правильно прив’язані, уникайте гарячої переназначення в продукції.

5) «SR‑IOV VFs в великих групах і їх не можна чисто призначити»

Симптом: VFs ділять групи з PF і іншими пристроями несподівано.

Корінь проблеми: ARI/ACS/прошивка; платформа групує їх, бо ізоляцію гарантувати не можна.

Виправлення: Увімкніть SR‑IOV і ARI у BIOS якщо доступно; переконайтеся, що прошивка актуальна; використовуйте NIC і платформи, які відомі хорошою поведінкою з VFIO.

6) «Усі пристрої в одній групі на ноутбуку/mini PC»

Симптом: Одна гігантська група, немає чистих розривів, мрії про зовнішній GPU тануть.

Корінь проблеми: Інтегрована топологія з обмеженим ACS, чіпсет‑корінна фабрика і модель безпеки, що не розрахована на детерміновану ізоляцію.

Виправлення: Прийміть обмеження; використайте паравіртуалізовані пристрої; або перейдіть на апарат, розроблений для цього.

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

Покроково: від «спільної групи» до «чистої ізоляції»

1. Базове увімкнення: підтвердьте DMAR/AMD‑Vi у dmesg і наявність груп.
2. Визначте цілі: перелічіть PCI‑адреси пристроїв, які хочете передати.
3. Мапуйте групи: виведіть членство груп і підтвердіть, хто з ким ділиться.
4. Намалюйте upstream‑ланцюг: використайте lspci -tv, щоб знайти upstream‑мости/порти.
5. Перевірте ACS на кожному релевантному порті: lspci -vv на root/низхідних портах у шляху.
6. Спробуйте просте виправлення топології: перемістіть карту в інший слот; видаліть/перемістіть M.2/райзери, що викликають перенаправлення ліній.
7. Перевіряйте групи після кожної фізичної зміни: не робіть масових змін — втратите причинно‑наслідковий зв’язок.
8. Налаштування прошивки: увімкніть VT‑d/AMD IOMMU, Above 4G decoding, SR‑IOV/ARI за потреби; оновіть BIOS.
9. Визначте ставлення до ризику: якщо потрібно ACS override — зафіксуйте чому, що саме в групі і який радіус ураження.
10. Прив’язуйте драйвери тільки після коректної ізоляції: присвоюйте пристрої vfio-pci, коли групи стали «нормальними».
11. Протестуйте шляхи скидання: старт/стоп VM кілька разів і слідкуйте за «зависанням» пристрою.
12. Оперешналізуйте: зберігайте топологію + маппінг груп як артефакт для виявлення дрейфу в майбутньому.

Чекліст: готовність до продукції для passthrough

• Критично важливі для хоста сховище/мережеві пристрої не знаходяться в жодній групі, яку плануєте призначити.
• Жодного ACS override у продукції, якщо він не схвалений і ризик не прийнятий.
• Версії прошивок зафіксовані і протестовані на регресії топології під час оновлень.
• Поводження з скиданням пристроїв перевірено (холодний старт, теплий ребут, цикли старт/стоп VM).
• Моніторинг включає PCIe AER помилки, IOMMU‑faults і скидання драйверів пристроїв.

Чекліст: коли варто зупинитися і купити інше залізо

• Цільовий пристрій ділить групу з чипсетним SATA/USB/NVMe, який потрібен хосту, і немає альтернативного слоту/root‑порту.
• Upstream‑порти не мають ACS‑можливостей і ви не можете змінити топологію.
• Прошивка не має відповідних перемикачів і оновлення не змінюють поведінку.
• Система вимагає ACS override для роботи, і у вас мульти‑орендне або регламентоване середовище.

FAQ

1) Якщо IOMMU увімкнено, чому мої пристрої все ще в одній групі?

Тому що увімкнення ≠ ізоляція. Групування відображає, чи може PCIe‑фабрика забезпечити розділення (поведінка мостів/ACS), а не лише наявність ремапінгу DMA.

2) Чи нормально, що GPU і його аудіо‑функція ділять групу?

Так. Це один фізичний пристрій, що експонує кілька PCI‑функцій. Зазвичай їх передають разом.

3) Чи можна передати лише один пристрій із спільної групи?

Не безпечно. VFIO вимагає призначення на рівні групи, бо будь‑який пристрій у групі може виконувати DMA, що вплине на інших. Якщо ви розділите її «взламом», ви погоджуєтеся на невизначену поведінку і ризики безпеки.

4) Чи розділить мої IOMMU‑групи увімкнення «Above 4G decoding»?

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

5) Чи впливає iommu=pt на групування?

Ні. Це впливає на те, як хост мапить DMA для пристроїв, що залишаються у хості, часто покращуючи продуктивність. Формування груп пов’язане з топологією і ACS, а не з passthrough vs translated mapping.

6) Яка найбезпечніша альтернатива, якщо не вдається отримати чисті групи?

Не використовуйте повний passthrough. Використайте паравіртуалізовані пристрої (virtio), шаровий доступ до GPU через API (де доступно) або перейдіть на апарат з кращою PCIe‑ізоляцією.

7) Чому мої IOMMU‑групи змінюються при додаванні NVMe або використанні іншого слота M.2?

Через спільне використання ліній і біфуркацію. Багато плат перенаправляють лінії залежно від заповненості сокетів. Це може пересунути пристрої за різні мости/комутатори і змінити ізоляцію.

8) Чи завжди небезпечний ACS override?

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

9) Мої групи в порядку, але passthrough все одно не працює. Що робити далі?

Перевірте прив’язку драйверів, поведінку скидання пристрою, помилки виділення ресурсів прошивкою і чи пристрій підтримує FLR. Групування є необхідною умовою, але не достатньою.

10) Чому сервери «просто працюють» частіше, ніж десктопи?

Більше root‑портів, кращий бюджет ліній, послідовніший дизайн комутаторів PCIe і прошивка, що серйозніше ставиться до ACS і SR‑IOV. Також постачальники серверів очікують гучні скарги від віртуалізаційних клієнтів.

Висновок: наступні кроки, що дійсно рухають ситуацію

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

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

1. Запустіть команду інвентаризації груп і виділіть точних небажаних співмешканців у цільовій групі.
2. Використайте lspci -tv і lspci -vv, щоб знайти upstream‑ланцюг і чи існує ACS там, де це важливо.
3. Спробуйте одне змінення топології за раз: перемістіть карту в інший слот, змініть населення M.2, перемикайте біфуркацію/настройки PCIe, оновіть прошивку.
4. Якщо все ще потрібен ACS override — зафіксуйте ризики, які пристрої ділять фабрику і як виглядає збій — і тоді приймайте рішення свідомо.
5. Оперешналізуйте: зберігайте відому‑добру мапу IOMMU‑груп як регресійний тест, щоб «дрібна апаратна ревізія» не стала наступним інцидентом.