4. Емулятори віртуальних машин
Окрема історія - це системи, що забезпечують повністю програмну емуляцію нікого віртуального комп'ютера без залучення його реальних апаратних ресурсів. Найбільш яскравим прикладом подібного емулятора є відома Java, в якій програмне забезпечення реалізує для кожного Java-додатки стандартну віртуальну Java-машину, яка не має абсолютно нічого спільного з реальним апаратним забезпеченням і працює з не має альтернатив системою «машинних» команд - байт-кодом Java. Кожна інструкція з цього байт-коду (а там зустрічаються і досить нетривіальні «екземпляри») «розбирається» програмою-емулятором вручну - емулятор самостійно, без будь-якої апаратної підтримки виконує відповідні інструкції дії з існуючою (знову ж таки, лише в чисто програмному вигляді) віртуальною машиною.
У емуляторів дуже багато переваг. Реалізовані ними віртуальні машини можуть бути як завгодно складні і, що важливіше, принципово відрізнятися від реальної фізичної машини, засобами якої вони підтримуються. Одне й те ж Java-додаток може бути запущено практично на будь-якому «залізі»; емулятор Спектр дозволяє виконувати додатки, написані для процесора Z80 на процесорах архітектури x86, і т.д. Класичні віртуалізатор всього цього робити, на жаль, не дозволяють, - запустити, скажімо, на x86, додаток для MacOS (використовує архітектуру PowerPC) з їх допомогою принципово неможливо.
Слабкі місця емуляторів цілком очевидні: оскільки апаратні ресурси процесора задіюються дуже опосередковано (де можна було б обійтися однією машинної інструкцією, доводиться виконувати від сотень до десятків тисяч машинних інструкцій для виконання однієї інструкції емульованого коду), то і продуктивність переважної більшості емуляторів просто катастрофічно мала. Навіть в Java, розробники якого чудово передбачали цю ситуацію і використанням складного байт-коду постаралися звести виникає надлишок роботи до мінімуму (чим простіше інструкція, тим помітніше час, що витрачається емуляторів на її «декодування» - визначення, що ця інструкція означає), повністю позбутися від цих проблем, на жаль, не вдалося: «важкі» Java-додатки відчутно «гальмують» і споживають велику кількість оперативної пам'яті.
Кілька разів робилися серйозні спроби виправити це положення справ, відмовившись від виконання коду «на льоту», коли емулятор послідовно, інструкція-за-інструкцією, транслює програму, і перейшовши до «динамічної компіляції програм», коли програма, записана в одній системі команд попередньо «переводиться» в «рідну» систему команд даного процесора, і вже потім, у вигляді отриманого «рідного» коду на цьому процесорі виконується. Приміром, розроблений Connectix, пізніше купленої Microsoft, продукт Virtual PC для Macintosh дозволяв, за рахунок такого «перекомп» додатків для операційних систем Microsoft, запускати ці програми на комп'ютерах Apple Macintosh. А компанія Transmeta в 1999 році навіть випустила абсолютно унікальний процесор Crusoe (VLIW-архітектури), який імітував «видимість» x86-архітектури за допомогою спеціального полуаппаратного емулятора, розробленого, до речі, за участю Лінуса Торвальдса. А пізніше Microsoft розробила на основі даного підходу і «удосконалену альтернативу» Java - технологію. Net, що використовує для запису програм спеціальний «універсальний код» КСС (Common Intermediate Language), який за своєю суттю аналогічний псевдокод, який генерують у ході своєї роботи сучасні компілятори перед тим, як сконвертувати цей «абстрактний код» до цілком конкретні машинні інструкції.
Потенційно даний підхід позбавлений всіх «вузьких місць», пов'язаних з недостатньою продуктивністю звичайних емуляторів, проте технологія. Net до цих пір так і не отримала обіцяного розповсюдження, а продуктивність Virtual PC для Macintosh, так само як і Transmeta Crusoe, залишає бажати кращого.
Після всіх компліментів на адресу AMD Pacifica може здатися, що нічого принципово більш сучасного в технологіях віртуалізації придумати неможливо. Але насправді це далеко не так.
Проведемо невеликий уявний експеримент. У нас є один комп'ютер з якимось набором апаратного забезпечення (яке, по суті, зводиться до процесора, оперативної пам'яті і засобів вводу-виводу). З пам'яттю і процесором ми вже розібралися: вони чудово віртуалізуются, і тому припустимо, що на цьому «залізі» працюють відразу декілька операційних систем. А ось хто і як працює з цих операційних систем з «введенням-виводом»? Ну, допустимо, різні жорсткі диски та логічні розділи цих дисків ми ще як-небудь розкидані між різними ОС. А ось візьмемо ту ж відеокарту: яка з операційних систем з нею повинна працювати? Не передавати ж її «по руках», перекидаючи від однієї ОС до іншої, - адже про присутність «сусідів», «підлаштовуються» під себе відеокарту ці ОС можуть навіть і не підозрювати!
Що робити? Єдине розумне рішення - застосувати все ту ж віртуалізацію до наших апаратних ресурсів. Замість того щоб працювати з цілком конкретної відеокартою, гостьові ОС працюють з якоюсь її «імітацією», яку створює модуль VMM, синхронізуючий потім цю імітацію з реальною відеокартою. Але оскільки на дійсно складну імітацію сил програмістів зазвичай не вистачає, то і можливості «віртуальної» відеокарточкі виходять відповідні, зразка десь 1996 року в кращому випадку. Щоправда, менш «наворочені» пристрою, на щастя, імітувати куди простіше, так що в дійсності ситуація далеко не так удручающа, як це може на перший погляд здатися, проте ж свого дозволу вона, безумовно, все-таки вимагає. А називається це все «віртуалізацією введення-виведення».
Зараз, правда, важко загадувати в майбутнє: коли ми ставили запитання співробітникам Intel, то з'ясовувалося, що відповідні проекти поки носять статус дослідницьких, а вже намірів по створенню і просуванню будь-яких стандартів у цій галузі у них ще немає і в помині. Але можна ризикнути припустити, що розвиток тут піде у бік часткового перенесення драйверів пристроїв з операційних систем в менеджери віртуальних машин (VMM). Кожен такий драйвер буде надавати певний універсальний інтерфейс до всіх можливостей відеокарти, що враховує при цьому існування багатьох «споживачів» цих можливостей; драйвера ж рівня операційної системи будуть просто надавати більш високорівнева доступ до тих же функцій у термінах специфічною для даної операційної системи графічної підсистеми (будь то Windows GDI з DirectX або X Window System з OpenGL). Благо, що на прикладі AMD Pacifica добре видно, що і «місце» під драйвера поруч з VMM в системах «другого покоління» чудово знайдеться, і інтерфейс між VMM і операційними системами (і навіть прикладним ПЗ) можна зробити надзвичайно зручним і швидкодіючим (можливо навіть більш швидким, ніж традиційні системні виклики). Самі ж «пристрої введення-виведення» також обзаведуться специфічними апаратними доробками, які спрощують можливості їх одночасного використання декількома операційними системами одночасно. Ймовірно, з'явиться і свій стандарт на VMM і «програмний інтерфейс» VMM, що надаються ними розширені можливості для звичайних операційних систем. І, цілком можливо, що зовсім недалеко той день, коли на типовому комп'ютері буде встановлений «вінегрет» з пари версій Microsoft Windows, Linux, FreeBSD, Solaris, якого-небудь популярного VMM з відкритим кодом, і все це різноманіття буде чудово, без сьогоднішніх проблем з драйверами для різних ОС, одночасно в повну силу працювати.
0 комментариев