Як вендори IA-32 підклали свиню творцям систем віртуалізації

    Навряд чи зараз когось здивуєш тим, що розвитком архітектури IA-32 займається не тільки Intel, але і такі компанії, як AMD і VIA. Більше інформації можна знайти, наприклад, у статті A. Fog'a . Сьогодні я планую розповісти про один, на мій погляд, не до кінця продуманому зміні ISA, внесеному компанією AMD.
 
 http://technology.desktopnexus.com/wallpaper/911325
 
При думках про вплив AMD на архітектуру IA-32 в першу чергу згадується REX префікс та підтримка 64-бітного режиму процесора. І це безумовно «позитивний» ефект, який зробив IA-32 краще. Проте були й інші цікаві зміни, які особисто я позитивними назвати не можу.
 
Кодування системи команд IA-32 внаслідок тривалої еволюції перетворилася на архіскладне структуру (одні тільки префікси чого варті). Розповідаючи про деякі проблеми декодування і їх рішеннях в статтях «Чи правильно працює ваш дізассемблер?» і «Як впоратися з IA-32 кодом або особливості декодера Simics» , я забув згадати кілька цікавих фактів. Максимально можлива довжина IA-32 інструкції — 15 байт. Префіксів в кодуванні може бути присутнім декілька і їх кількість фактично обмежене тільки умовою на довжину інструкції. При цьому один і той же префікс може зустрітися кілька разів, або, наприклад, можуть зустрітися префікси, які ніяк не можуть вплинути на дану інструкцію. Всі вони будуть просто проігноровані.
 
На мій погляд, непоганий приклад, який ілюструє дану ситуацію, можна привести на основі інструкції
NOP
(No OPeration — інструкція, яка не робить нічого. Кодування
0x90
).
 
 
0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x90
— це теж інструкція
NOP
, всі 14 префіксів
0x66
просто ігноруються.
 
Це, безумовно, дуже дивна особливість, але від неї вже нікуди не дітися. А деякі компілятори взагалі можуть використовувати префікси для вирівнювання коду.
 
 

На цьому квіточки закінчилися, починаються ягідки.

 
 
 
Вже багато років в интеловской архітектурі існує інструкція
BSR
. Вона вперше з'явилася в процесорі Intel 80386 . Вона знаходить порядковий номер найбільш значимого біта рівного 1.
 
Наприклад, для числа
0x11aa00bb
дана інструкція поверне 28.
 
Подивимося, як її можна закодувати:
 
 
 
Нічого цікавого:
0x0F 0xBD
і Mod R / M байт для операндів.
 
А тепер давайте додамо до кодуванні цієї інструкції небудь префікс… Скажімо
0xF3
. Вийде валідна інструкція, префікс буде просто проігнорований, так як ставиться до строковим операціям або інструкціям введення / виводу. Ніякого криміналу.
 
 
Що, власне, зробили товариші з AMD?
Провівши деякий дослідження, вони виявили, що комбінація префікса
0xF3
з інструкцією
BSR
в програмному забезпеченні зустрічається дуже рідко, і перепрофілювали дану комбінацію в нову інструкцію —
LZCNT
, яка обчислює кількість провідних нулів.
 
Для того ж вхідного числа
0x11aa00bb
в 32-бітному режимі дана інструкція поверне не 28, а 3.
 
 
 
З'явилася ця інструкція про склад розширення команд ABM (Advanced Bit Manipulation), що складається з двох інструкцій
LZCNT
і
POPCNT
(у цій команді, особисто я нічого поганого не бачу), кожна з яких при цьому має окремий біт в CPUID .
 
Відключити цю інструкцію, на жаль, ніяк не можна.
 
Першим набір команд
ABM
підтримав процесор AMD, заснований на мікроархітектурі Barcelona . Компанія Intel додала інструкцію
POPCNT
в набір команд процесора Nehalem. І можна було подумати, що Intel зупиниться на цьому, але ні. Інструкція
LZCNT
з'явилася в процесорах Haswell.
 
 
Чим же це погано?
По-перше, дана зміна, очевидно, порушує зворотну сумісність. Але це, на мій погляд, не найгірше її властивість. Як згадувалося вище, згідно з дослідженнями AMD, інструкція
BSR
з даними префіксом зустрічається вкрай рідко. І все-таки чисто теоретично така ситуація можлива.
 
Але стаття не про це, так що давайте тепер відійдемо трохи від типових потреб рядового користувача і подивимося на потреби розробників.
 
Як відомо більша частина програмного стека пишеться та налагоджували на симуляторі ще до випічки самого чіпа. Так що давайте подивимося, як дана зміна може вплинути на швидкість і точність симуляції.
 
Зрозуміло, всім хочеться моделювати якомога швидше. Швидкості звичайного інтерпретатора ніколи не вистачає. Всі хочуть вантажити BIOS за секунди, а операційну систему за лічені хвилини. З цієї причини модель значно ускладнюється, з'являється оптимизирующий двійковий транслятор , що дозволяє скоротити час роботи симулятора. Але цього все одно недостатньо! Додають підтримку прямого виконання гостьових інструкцій на хості, що ще ускладнює модель, покращуючи при цьому продуктивність в кілька разів. Докладніше про різні режими роботи симулятора можна почитати в статті «Програмна симуляція мікропроцесора. Коробка передач ».
 
Нескладно здогадатися, що ні в інтерпретаторі, ні в трансляторі ніяких проблем виникнути не повинно. Проблеми можуть виникнути в разі використання апаратної віртуалізації . Ні
LZCNT
, ні, тим більше,
BSR
не викликає виходу в монітор ВМ.
 
Це призводить до того, що якщо вам знадобиться симулювати Haswell + процесор, то на більш старому процесорі, наприклад на Sandy Bridge, ви можете виконати
BSR
замість
LZCNT
. І навпаки, якщо ви захочете моделювати небудь більш простий процесор, наприклад, Quark на хості з Haswell, ви ризикуєте отримати протилежний ефект —
LZCNT
замість
BSR
.
 
Вони зламали віртуалізацію!
 
 http://oneinjesus.info/2010/04/the-sad-story-of-my-broken-computer/
 
Проте вирішення цієї проблеми є — попередній перегляд сторінки.
 
Існуючий механізм віртуалізації дозволяє обмежити набір сторінок пам'яті, до якому може звертатися гостьове ПЗ. Таким чином ми можемо дозволити пряме виконання коду, що знаходиться тільки на сторінках не містять кодувань
LZCNT
інструкції. А кожну нову сторінку попередньо сканувати на наявність даних команд.
 
Така зміна, зрозуміло, призводить до падіння продуктивності і ускладнення без того не простого симулятора. Саме в цьому, як мені здається, і полягає негативний ефект даних змін.
 
P.S. Така інструкція не єдина. Разом з розширенням BMI1 Intel додав нову інструкцію
TZCNT
, яка аналогічним чином пов'язана з командою
BSF
.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.