Технології віртуалізації: вчора, сьогодні, завтра

СОДЕРЖАНИЕ: Віртуальна память і стандартні інтерфейси операційних систем, захист важливих ділянок оперативної памяті від перезапису. Паравіртуалізація і бінарна трансляція, конфігурація віртуальних машин. Типи віртуальних середовищ програм і операційних систем.

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КРАСНОДОНСЬКИЙ ПРОМИСЛОВО ЕКОНОМІЧНИЙ КОЛЕДЖ

Реферат з предмету: «Операційні системи»

На тему:

«Технології віртуалізації: вчора, сьогодні, завтра»

Студента групи 1ОКІСМ-06

Петренко Михайла

Перевірила: Дрокіна Т. М.

Краснодон

2009

Зміст

Вступ

1. Віртуалізація позавчора: віртуальна память і стандартні інтерфейси операційних систем

a) Паравіртуалізація і бінарна трансляція

b) VMWare Workstation і VMWare Server

c) Microsoft VirtualPC / Virtual Server

2. Віртуалізація сьогодні і завтра: Intel VT і AMD «Pacifica»

d) Віртуалізація завтра: AMD Secure Virtual Machine «Pacifica»

3. Інші підходи до віртуалізації. Віртуальна машина Xen

4. Емулятори віртуальних машин

Вступ

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

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

Підвищений інтерес до компютерних технологій віртуалізації в даний час не випадковий. Обчислювальна потужність нинішніх процесорів швидко зростає, і питання навіть не в тому, на що цю потужність витрачати, а в тому, що сучасна «мода» на двоядерні і багатоядерні системи, що проникла, вже і в персональні компютери (ноутбуки та десктопи), як не можна краще дозволяє реалізувати багатющий потенціал ідей віртуалізації операційних систем і додатків, виводячи зручність користування компютером на новий якісний рівень. Технології віртуалізації стають одним з ключових компонентів (у тому числі, і маркетингових) в самих нових і майбутніх процесорах Intel і AMD, в операційних системах від Microsoft і ряду інших компаній. І найближчим часом ми можемо побачити на цьому полі не менш жаркі баталії, ніж ті, що недавно гриміли з приводу підтримки 64-бітних інструкцій чи двоядерними в процесорах Athlon і Pentium. Отже, тут ми зробимо спробу розібратися, в тому числі, з технічного боку (не вдаючись, однак, занадто глибоко в деталі), що являють собою апаратні технології віртуалізації в процесорах Intel і AMD, а також розглянемо програмні рішення по віртуалізації від різних виробників, без чого застосування віртуалізації в компютерах також немислимо.

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

1. Віртуалізація позавчора: віртуальна память і стандартні інтерфейси операційних систем

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

Але що ж тоді ховається за модними в останні півроку словами «технології віртуалізації», які, як запевняють нас гранди процесоробудування, стане не менш вагомим аргументом у питанні купівлі нового процесора, ніж ще роки два тому була збільшена продуктивність?

У більшості російськомовних читачів слово «віртуальний», всупереч його споконвічного походженням, напевно, викликає приблизно однакові асоціації з чимось нематеріальних, неіснуючим насправді. Але початковий сенс його в обчислювальній техніці набагато конкретніше і простіше - «віртуальні» обєкти тут завжди означають якісь абстрактні інтерфейси, за якими ховається реальний обладнання. Основна ідея, добре простежується тут останні років двадцять - це прагнення максимально спростити завдання розробникам програмного забезпечення, надавши кожній програмі (в ідеалі) за стандартним «віртуального компютера», на якому вона зможе працювати без обліку взагалі яких би то не було сторонніх чинників - компютера, на якому вона запущена, або інших працюють на цьому ж компютері програм. І, треба сказати, результати тут були досягнуті вражаючі. Перші процесори працювали безпосередньо з «фізичною» оперативною памяттю, безпосередньо вказуючи в програмі конкретну комірку в модулі памяті, з якою вони працювали. Виходило щось на кшталт «модуль памяті # 1, мікросхема 4, банк 3, рядок даних 63, байт 13, - або, у двійковій нотації,« модуль 01, мікросхема 01000, банк 11, рядок даних 0111111, байт 01101 ». Ці числа записувалися підряд - і виходив адресу 010100011011111101101, тобто 669 677 у звичній нам десятковій нотації. При дотриманні мінімальних обмежень на організацію модулів памяті при такому способі запису фактично виходить, що ми нумеруючи елементу памяті що йдуть підряд числами, починаючи з нуля і закінчуючи деякими великим числом. А це зручно і проектувальникам «заліза», і програмістам. (До речі, саме звідси пішло правило «обсяг модуля памяті повинен бути ступенем двійки» - при такому підході всі молодші біти фізичної адреси модуля виходять допустимими, і в нумерації адрес фізичної оперативної памяті не виникає «дірок»). Ось з цими «фізичними адресами памяті», що утворюють відрізок на числової прямої, перші програми і працювали. Система була за своїм досить витончена, але, на жаль, абсолютно не пристосована для одночасного виконання кількох програм, - в кращому випадку одна програма в компютері могла на час передавати управління іншій.

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

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

Схема 1. Компьютер без виртуализации

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

Подібна система називається сегментованої моделлю оперативної памяті, в архітектурі x86 вона зявилася в процесорах i80286 (де отримала назву «захищеного режиму») і зникла з цієї архітектури тільки з переходом до 64-бітним розділами інструкцій AMD64/Intel EM64T.

Схема 2. Сегментована память

Що ми отримуємо від переходу до сегментації? По-перше, захист одних програм від інших: процесор перевіряє кожне звернення програм до памяті і контролює, щоб вони не вийшли за межі виділених їм сегментів. По-друге, - і, мабуть, це навіть набагато важливіше - радикальне підвищення зручності програмування. Нам не потрібно замислюватися над тим, що на нашому компютері взагалі існують інші програми - кожній з них забезпечено «віртуальне» простір, у якому є навіть не одна, а цілих три незалежних один від одного, «памяті», виділені їй і тільки їй, де зберігаються ключові структурні частини будь-якої запущеної програми - код, дані і стек. Нам не потрібно підлаштовуватися під особливості конкретної версії операційної системи (а це ж теж як мінімум ще одна програма, запущена на компютері!), Ми можемо використовувати для всіх випадків життя абсолютно однаковий програмний код.

Ефективна схема? Цілком! Вона працює, вона зручна, доступна і зрозуміла, тому що багато любителі асемблера до цих пір із задоволенням нею користуються. Але довго вона не протрималася, оскільки, як легко здогадатися, особливою гнучкістю у використанні не відрізняється. Як ми з самого початку «наріжемо» память скибочками, - так воно в майбутньому і залишиться: виділимо занадто багато - якісь області залишаться невикористаними і простоюють; виділимо занадто мало - не зможемо в потрібний момент збільшити цей обсяг. Чи памятають ще програмісти старі добрі DOS-Овские середовища розробки від Borland, де в опціях компілятора вказувалася «модель памяті», в якій визначався розмір і кількість використовуваних у програмі сегментів? І чи памятають користувачі чудову утілітку mem і знамените Not enough memory, якими так радували око користувача ранні «персоналки»?

Одним словом, навіть у ті часи існували кращі рішення, і в наступному, першому по-справжньому сучасному поколінні x86-х процесорів (80386) слідом за процесорами Motorola і мейнфреймах зявилася основа будь-яких сучасних багатозадачних ОС - віртуальна память. Про вдалість цієї розробки говорить хоча б те, що аж до переходу до 64-бітним розділами інструкцій «ядро» будь-яких x86 в точності відповідало стандарту IA-32 (Intel Architecture for 32-bit), введеному Intel для i386 (так що, в принципі, на «трешка» повинні працювати будь-які 32-бітові програми, не задіюються занадто сучасних функцій).

Віртуальна память (схема 3) - це логічний розвиток ідеї сегментованої памяті, коли ми переходимо від цілком конкретним чином перетворюються у фізичні «лінійних» адрес захищеного режиму x86 до абсолютно абстрактним «віртуальним» адресами. Адже, за великим рахунком, для працюючої на компютері програми зовсім байдуже, що за «фізичні» осередку памяті вона використовує! Їй потрібний просто деякий діапазон адрес, за якими вона зможе зберігати свої дані, а що за цими «ціфіркамі» насправді криється, їй глибоко байдуже. Головне - щоб процесор знав, як ці абстрактні цифри (віртуальні адреси) переводити в цілком конкретні інструкції для контролера памяті (фізичні адреси).

Схема 3. Віртуальна память

Як це робиться на практиці? Вся доступна процесору фізична оперативна память розбивається на невеликі шматочки розміром 4 Кбайт або 4 Мбайт - «сторінки». При цьому використовується та ж схема, що й при розбивці фізичних адрес на адреси конкретної комірки памяті: молодші 12 або 22 біт віртуального адреси позначають зміщення цієї адреси від початку сторінки, а старші біти (від 10 до 50) - номер сторінки. Коли процесору потрібно обчислити фізичну адресу з віртуального, він просто розділяє віртуальний адресу на номер сторінки і зсув, заглядає в таблицю, де для кожного номера вказані координати початку сторінки у фізичній памяті, і додає до отриманої координаті зміщення (схема 4). Згадана табличка сторінок називається таблицею трансляції адрес віртуальної памяті (або просто таблицею трансляції), і розміщується вона у вигляді B-дерева в самій звичайної оперативної памяті, що дозволяє створювати без великої надлишковості як завгодно великі швидкодіючі таблиці трансляції. Працює це дерево, правда (як і все, повязане з оперативною памяттю), як і раніше не дуже швидко, і тому процесор кешує раніше певні відповідності «номер сторінки - запис у таблиці трансляції» в спеціальному сервері - буфері трансляції віртуальних адрес (Translation Look -aside Buffer, TLB).

Схема 4. Робота з віртуальною памяттю.

Деталі таблиці трансляції

Фраза про B-дерево може прозвучати страхітливо, але насправді ховається за цим не така вже й складна технологія. Двійковий номер віртуальної памяті, за все тією ж доброю традицією, «розрізається» на кілька шматочків невеликого розміру (по 10 біт): наприклад, 00000000001111111111010101010101 - перетворюється на 0000000000 + 1111111111 + 010101010101. Перша частина адреси - 0 - це «номер директорії», друга - 1023 - «номер сторінки», третя - 1365 - зміщення від початку сторінки.

Що далі з цим усім робити? У процесорі є спеціальний регістр під назвою CR3 (Control Register # 3), в якому записується «вказівник на таблицю трансляції» - фізичну адресу, по якому в памяті розташовується «таблиця директорій». Ця сама таблиця - це 1024 записи довжиною по 32 (або 64) біта, в яких записані фізичні адреси «таблиць сторінок», відповідних тій або іншій директорії. У нас директорія номер нуль, а тому процесор, декодує віртуальний адреса, обчислює суму регістру CR3 з нулем і отримує адресу потрібної йому «таблиці сторінок». Ось у цій таблиці (теж з 1024 записів завдовжки 32 або 64 біта) вже записані фізичні адреси почав сторінок, так що, додавши до початку таблиці сторінок номер сторінки (1023) - ми виходимо на запис, в якій знаходиться фізичну адресу початку потрібної нам сторінки. Залишається тільки додати до нього 1365 - зміщення - і шуканий фізичну адресу готовий. У разі 64-бітної організації памяті рівнів трансляції в цій схемі не два, а чотири; у разі трансляції зі сторінками розміром 4 Мбайт - останній рівень трансляції пропускається.

Навіщо взагалі знадобилася така складна схема і чому було не можна обмежитися однією таблицею трансляції? Вся справа в розмірі таблиць. Для 32-бітної адресації памяті і сторінок розміром 4 Мбайт необхідний розмір таблиці складає всього лише 4 або 8 Кбайт памяті, але для більш затребуваних 4 Кбайт - сторінок, і, ще гірше, для 64-бітної адресації памяті, необхідні розміри таблиці виходять набагато більшими - від 4-8 Мбайт до 8 Гбайт і навіть 8 Тбайт. За часів 386-х процесорів навіть 4 Мбайт для таблиці трансляції адрес однієї програми здавалося занадто великою цифрою (а, враховуючи, що на компютері можуть бути одночасно запущені сотні програм, і для кожної потрібно мінімум по 4 Мбайт фізичної памяті - це і для сучасних систем надто багато), і тому вибір був зроблений на користь дворівневої трансляції, при якій трансляцію можна зупинити ще на «верхньому» рівні, вказавши для деяких записів у «таблиці директорій», що вони не відповідають жодним реальним фізичним адресами і прибравши, таким чином, необхідність у вказівці для цілого діапазону адрес записів у таблиці трансляції.

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

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

Захист важливих ділянок оперативної памяті від перезапису.

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

Захист програм від вірусів.

Основа новомодних «антивірусних» технологій на кшталт Microsoft Data Execution Prevention, що забезпечують надійний захист компютера від експлойтів, що використовують атаки типу «переповнювання буфера», - крихітний Битик в таблиці трансляції (No eXecute - NX в AMD, і eXecute Disable, XD - у Intel), що забороняє виконання машинного коду з певних ділянок памяті.

Захист операційної системи.

Спеціальний біт дозволяє визначити деякі ділянки оперативної памяті як «системні» і принципово недоступні звичайному додатком як для читання, так і для запису.

Ефективний менеджмент оперативної памяті.

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

Але найголовніший біт в таблиці трансляції - це «нульовий» біт P - Present, що забезпечує власне

По-справжньому віртуальну память.

Насправді, призначення цього біта досить просте - якщо він «скинутий» (встановлено в 0), то будь-яке звернення до оперативної памяті за цією адресою викликає системну помилку (виключення), що називається Page Fault (# PF). Але скільки ж на основі цієї «простоти» вдається побудувати! Адже, по суті справи, P-морський прапор - це зазначення процесору, що для обробки звернення програми до даного адресою памяті потрібно звернутися за допомогою до операційної системи.

Судіть самі: найпростіше застосування P-прапора - це реалізація своп-файлу, що дозволяє використовувати жорсткий диск замість фізичної оперативної памяті. Ідея в тому, що ми можемо для деяких сторінок віртуальної памяті не ставити їм у відповідність ніякого фізичної адреси оперативної памяті, а «скинути» для відповідних записів у таблиці трансляції P-прапор і зберегти сторінку у файл на жорсткому диску. Якщо звернень до даної сторінки не відбувається - то все добре. Якщо відбувається - то генерується виключення # PF. По суті своїй процесор просто припиняє виконання поточної програми, і заглядає у свій «довідник щодо дій у нештатних ситуаціях» - спеціальна ділянка памяті, в якому прописано, яку підпрограму операційної системи викликати в тому чи іншому випадку. У повній відповідності зі стандартом, процесор викликає обробник виключення # PF - один з ключових фрагментів будь-якої операційної системи. Обробник (фактично - операційна система) - «дивиться» на виниклу ситуацію («програма така-то полізла в память за адресою такому-то і була зупинена тому що прапор Present був скинутий»), визначає, що цією адресою відповідає сторінка памяті, якої немає в оперативній памяті, але яка є на жорсткому диску - і починає діяти:

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

2. Читає потрібне місце своп-файлу, копіюючи дані з неї в цю сторінку.

3. «Модернізує» таблицю трансляції, прописуючи в ній новий фізичну адресу для сторінки, через яку стався збій.

4. Оновлює при необхідності дані в буфері TLB.

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

Інші «популярні» застосування P-прапора віртуальної памяті дозволяють реалізовувати, приміром техніку «меппінга файлів на память». «Меппінга» - це коли програма за технологією, аналогічної техніки свопінгу, відображає за запитом програми той або інший файл у простір віртуальних адрес програми. Тобто можна домогтися того, щоб читання з елементу памяті # 13323658 виливалася б у автоматичне читання якого-небудь файлу program.data з позиції 3446. Це, по-перше, дуже зручно (файл не потрібно «читати» або «писати» - він вже доступний програмі у вигляді звичайного масиву або набору масивів), по-друге, дуже швидко (виробляється лише мінімально необхідний набір дій по завантаженню або записи даних), а по-третє, дуже ефективно (файл автоматично «кешується» в оперативній памяті, невживані сторінки з цього кеша автоматично ж прибираються, звільняючи фізичну память, при збереженні зберігаються тільки дійсно змінилися фрагменти файлу, а не все підряд, і т. п.). Хоча з-за обмежень порівняно вузького доступного програмі, яка працює під управлінням 32-бітних версій Microsoft Windows, віртуального простору в 2-3 Гбайт, і дуже громіздкою і незручною реалізації даної техніки засобами Win32 API, використовується вона досить рідко.

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

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

· Віртуальна память має всі переваги сегментованої.

· Але при цьому розміри віртуальної памяті, виділеної програмі, можуть як завгодно гнучко змінюватися.

· Віртуальна память може «фізично» розміщуватися не тільки в оперативній памяті, але і на жорсткому диску і навіть у Мережі.

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

· Можна задавати довільне число «пересічних» областей віртуальної памяті для різних програм, аж до того, що одні й ті ж дані будуть багаторазово відображені в адресний простір програми за різними адресами.

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

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

Мінусів у віртуальній памяті всього два. По-перше, вона істотно уповільнює роботу компютера (навіть проста трансляція віртуальних адрес, які не потрапили в TLB - дуже неквапливий заняття; обробка ж події # PF - і зовсім здатна зайняти сотні тисяч тактів процесора), а по-друге, - складна і абсолютно непрозора для рядового програміста.

а) Паравіртуалізація і бінарна трансляція

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

І вже сама по собі подібна можливість дозволяє, насправді, реалізовувати практично все, що завгодно, з користувацькими додатками. Приміром, потенційно можна взяти, «зберегти» стан програми на флешку, «скопіювати» на інший компютер і «продовжити» виконання програми вже на іншому компютері. Можна (потенційно) запускати в одній і тій же операційній системі як Windows, так і POSIX-додатки (Linux, Unix-системи) - достатньо вміти створювати два «типу» віртуальних компютерів, щоб кожен додаток отримувало рівно те середовище виконання, в якій воно звикло працювати. Але, на жаль, для користувача, подібні «хитрощі», що вимагають активної підтримки з боку операційної системи, реалізувати на практиці далеко не так просто, як розповісти про них. І забезпечити, скажімо, «рідну» підтримку Windows-додатків в Linux, так само як і зворотний підтримку Linux-додатків в Windows, з причини активної протидії Microsoft, неможливо. А тому користувач змушений обходитися без деяких цікавих функцій і задовольнятися Windows-додатками на Windows-системах і Linux-додатками на Linux-системах.

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

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

Спосіб перший - це «спосіб свідомого співробітництва»: зводиться до того, що наші ОС будуть «враховувати інтереси» один одного, розподілять між собою апаратні ресурси, і надалі будуть працювати так, щоб не нашкодити своїми «надзвичайними повноваженнями» операційної системи іншій системі. Подібний підхід вельми широко практикується в * nix-подібних операційних системах і називається паравіртуалізаціей. Однак оскільки даний спосіб вимагає серйозної модифікації ядра ОС, на яке, приміром, усе та ж Microsoft, яка домінує на ринку операційних систем, природно, не погоджується, то особливої популярності серед «звичайних користувачів» він отримати не зумів.

Схема 5. Паравиртуализация

Другий спосіб дуже добре знаком «просунутим користувачам» згідно з додатками типу VMWare Workstation, що забезпечує успішний запуск на одному компютері з-під «базової» операційної системи кількох «гостьових» операційних систем без спеціальної їх модифікації. «Гостьова» операційна система разом з усіма її додатками фактично стає одним «звичайним» додатком «батьківського» операційної системи, з-під якої вона запущена. Ідея тут дуже проста: використовуючи віртуальну память, ми можемо зімітувати віртуальний компютер практично будь-якої складності: так що «гостьовий» операційній системі просто «підсовується» віртуальна машина, яка дуже схожа на «фізичну x86-машину. «Гість» приймає «обманку» за справжній компютер - і цілком успішно починає на цій віртуальній машині, імітованої «батьківського» ОС, працювати. Зверніть увагу, на те, що це не підхід, аналогічний «віртуальній машині Java» або емуляторам стародавнього Sinclair, коли програма-емулятор віртуальної машини «вручну» розбирає код додатку і «вручну» ж виконує кожну його інструкцію. Гостьова операційна система і всі запущені в її рамках програми працюють на фізичних ресурсах компютера практично так само, як це робить звичайне запущене на ньому додаток, а «віртуалізується додаток» тільки забезпечує контроль над ним - тонюсінька прошарок коду, підтримана стандартними апаратними ресурсами компютера. Давайте розберемо трошки детальніше, як таке виявляється можливим.

У нас є якісь апаратні ресурси, які треба імітувати. В архітектурі x86 їх, загалом-то, всього три:

· Регістри процесора (включаючи регістри службового призначення).

· Порти введення-виведення (що використовуються для обміну інформацією з периферією).

· Оперативна память.

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

Але є кілька неприємних винятків. Ось, приміром, уже згадуваний регістр CR3, керуючий таблицею трансляції оперативної памяті. Власне, знаючи «віртуальне» значення CR3, «базовою» операційній системі неважко зімітувати власне таблицю трансляції: достатньо повязані з цієї таблиці області віртуальної памяті помітити за допомогою P-прапора, отримати таким чином перехоплення всіх звернень до цієї таблиці, та синхронізувати реальну таблицю трансляції з віртуальною, яку гостьова операційна система приймає за реальну (техніка «тіньових таблиць трансляції», Shadow Page Table). Але при цьому, на жаль, потрібно якось обманювати гостьову операційну систему, «підсовуючи» їй «віртуальний CR3» замість реального, а коштів відповідного апаратного контролю звичайний x86-процесор не надає.

Схема 6. Віртуалізація з гостьовими ОС.

Ще одна проблема з тієї ж серії - внутрішній регістр процесора, що відповідає за «рівень привілеїв» поточного запущеного додатку. Процесор використовує його, щоб перехоплювати спроби звернення «звичайних» додатків до «небезпечним», «недозволеним» інструкцій і областях памяті; призначається цей рівень привілеїв операційною системою. Таких рівнів всього чотири; про додатки із заданим рівнем привілеїв говорять, що вони працюють у відповідному кільці. Чим менше чисельне значення даного параметра, тим більше можна відповідним додатків. У кільці 0 (Ring 0), приміром, працює операційна система і (зазвичай) драйвера операційної системи; в кільці 3 (Ring 3) - «звичайні» користувальницькі додатки. Так от: довіряти «гостьовий» операційній системі нульове кільце не можна - інакше неможливо буде перехоплювати деякі його дії, оскільки в нульовому кільці «дозволено все» і багато перевірки безпеки просто не працюють. Але оскільки гостьова операційна система, природно, за замовчуванням припускає, що її потрібно запускати саме в нульовому кільці, а перевірити цей факт особливої праці не представляє, то цілком природно, що при спробі її запуску в будь-якому іншому кільці додаток-віртуалізатор добється хіба що повідомлення про помилку. Тому, строго кажучи, повноцінну імітацію «фізичного» компютера за допомогою апаратних ресурсів віртуалізації в x86 не можна. Кажуть, що не виконано критерій самовіртуалізіруемості Попека і Голберга (Popek and Goldberg self-virtualization requirements).

Як же тоді працюють «віртуалізатор» типу VMWare? Досить нетривіальним чином. Віртуалізатор злегка «підрізає крила» коду виконується під його керуванням операційної системи, на льоту дізассембліруя її код і замінюючи «погані» інструкції (на кшталт читання-запису регістра CR3) нейтральними з її точки зору (це називається динамічної трансляцією; dynamic recompilation). Зробити це, мяко кажучи, не так вже просто, а гарантувати працездатність що виходить на виході результату - ще складніше. Приплюсуйте сюди задачку імітації софтом віртуального x86-компютера (що вимагає реалізації спеціального складного драйвера), і ви отримаєте уявлення про те, чому «віртуалізується ПЗ» для x86 до цих пір не відрізнялося ні особливою надійністю, ні особливою продуктивністю. На жаль, але в архітектурі IA-32 з її з самого початку непоганий віртуалізаційних функціональністю спочатку була закладена здоровенна «дірка», яку можливо обійти тільки з великими труднощами.

Цікаво, до речі, що в що прийшла на зміну IA32 технології AMD64/Intel EM64T, виправити більшість невдалих і тонких місць архітектури, що веде свій родовід аж з процесора Intel i80386, цю «віртуалізаційних дірку» ні Intel, ні AMD так і не закрили! Замість цього вони абсолютно незалежно один від одного випустили дві абсолютно несумісні один з одним «заплатки» до AMD64 і EM64T відповідно, по-різному що полегшують життя розробникам віртуалізаційних ПЗ.

b) VMWare Workstation і VMWare Server

У Росії імя VMWare є практично синонімічним для «програмного забезпечення для віртуалізації». Саме ця компанія в 1999 році вперше вивела на ринок успішний продукт, що забезпечував для операційних систем виробництва Microsoft можливість запуску віртуальних машин з «чужими» операційними системами. Правда, в 2003 році VMWare була скуплена корпорацією EMC2, до складу якої з тих пір і входить, проте свого існування як самостійного гравця з розкрученим брендом вона з тих пір не припинила. І поточна політика керівництва EMC2 полягає в тому, щоб VMWare і далі працювала на ринку як самостійна одиниця, впливати на стратегію і тактику якого EMC особливо не буде.

На сьогоднішній день VMWare пропонує три лінійки базового і деяку кількість супутнього віртуалізаційних ПЗ (таблиця-ца 1). Перша лінійка, VMWare Workstation 5.5 орієнтована насамперед на звичайних розробників, запускаючих на своєму компютері декілька операційних систем одночасно. Друга, VMWare Server GSX 3 - практично ідентична першої по основній функціональності, але орієнтована вже на серверне застосування в якості засобу організації безлічі захищених віртуальних серверів на одному фізичному. Існують версії обох пакетів для Windows 2000/XP/2003 та основних дистрибутивів Linux. Третя лінійка, VMWare Server ESX 2 коштує дещо окремо, оскільки орієнтована не на запуск в якості звичайного додатки в «батьківського» операційній системі, а, фактично, реалізує свою власну операційну систему, в якій запускається одно-єдина програма - власне віртуалізаційних ПЗ. Область застосування Server ESX приблизно та ж, що і у Server GSX, але ESX орієнтована на великі дата-центри, що вимагають особливої надійності від віртуалізується ПЗ.

Конфігурація віртуальних машин у VMWare більш ніж гідна. Ресурси процесора доступні віртуальній машині в повному обсязі (якщо на «батьківського» машині коштує Pentium 4 - в імітованих компютері буде стояти точно такий же процесор); обсяг оперативної памяті - практично необмежений (до 3,6 Гбайт на кожну віртуальну машину); підключаються безпосередньо або імітуються стандартні IDE-пристрої (жорсткі диски та оптичні накопичувачі у вигляді файлів на диску), підтримується пряме підключення SCSI-адаптерів і імітація SCSI-дисків, підключених через контролер LSI Logic Ultra160 або Mylex BT-958. Відеокарта - абстрактний графічний адаптер VGA / SVGA. Підтримується і емулюється до двох флоппі-дисків, до чотирьох COM-портів, UCHI-контролер на 2 порти USB 1.1; до двох паралельних LPT-портів, стандартна 104-кнопкова клавіатура і миша PS / 2. Підтримується до чотирьох віртуальних мережевих карт (AMD PCnet) і навіть віртуальна локальна мережа, що складається з довільного числа хостів і до девяти віртуальних світче. Загалом, звання лідера VMWare утримує цілком заслужено.

VMWare використовує у своїх продуктах класичну технологію «бінарної трансляції»; в останні версії ПЗ включена і експериментальна підтримка технології віртуалізації Intel VT-x. Підтримка технології віртуалізації AMD «Pacifica» обіцяна в самому найближчому майбутньому. До речі, саме продукти VMWare корпорація Intel використовувала ще рік тому для публічних демонстрацій (наприклад, в рамках Intel Developer Forum) майбутніх можливостей своїх процесорів з Virtualization Technology, тоді ще не оснащених блоками VT. І, слід зазначити, що, наприклад, на трехгігагерцовом процесорі Intel Xeon (ядро Nocona) робота такої віртуальної системи не відрізнялася особливою прудкістю, в чому нам довелося переконатися особисто.

с) Microsoft VirtualPC / Virtual Server

На відміну від VMWare, Microsoft ніколи до ладу не розробляла власних систем віртуалізації: що випускаються сьогодні під її брендом VirtualPC і Virtual Server спочатку були розроблені компанією Connectix. Але в 2003 році Microsoft скупила дані продукти у Connectix, що називається, «на корені», і з тих пір приблизно та ж команда розробників випускає лише злегка «підрихтувати» колишні продукти Connectix під Microsoft-івської маркою. Однією з сторін подібного переходу «під крило» Microsoft стало те, що відтепер VirtualPC працює виключно під управлінням десктопних версій ОС Windows XP/2000, а більш функціональний Virtual Server - і зовсім тільки під управлінням серверних Windows XP/2003 Server.

Спочатку віртуалізаційних ПЗ Microsoft був орієнтований на використання технології бінарної трансляції коду. Виняток - VirtualPC for Macintosh, який формально також використовує ту ж технологію бінарної трансляції, але по суті своїй є, швидше, просунутим емулятором (див. нижче). У 2005 році Microsoft також заявила про підтримку в своїх майбутніх продуктах технологій Intel VT-x та AMD SVM «Pacifica», проте бета-версії відповідних продуктів вийдуть лише в першій половині 2006 року, а остаточний реліз - у другій половині.

У частині обладнання VirtualPC і Virtual Server імітують один і той же «стандартний компютер» з процесором Pentium II (з підтримкою MMX), що працює на чіпсеті Intel 440BX, з відеокартою S3 Trio 64 PCI (з 4 Mb відеопамяті), BIOS від American Megatrends (AMI), звуковою картою Creative Sound Blaster 16 PnP (Virtual Server її не підтримує), і мережною картою DEC 21041 / 21040. Конфігурація хоч і старенька, але вельми поширена в свій час, а тому має дуже непогану підтримку з боку програмного забезпечення.

2. Віртуалізація сьогодні і завтра: Intel VT і AMD «Pacifica»

Корпорація Intel пішла досить прямолінійнім шляхом, просто випустив «мінімально необхідну» латочку до x86. Повна назва «заплатки» - Intel Virtualization Techology for x86 (VT-x); Одночасно була випущено аналогічна віртуалізаційніх «технологія» для процесорів Intel Itanium (VT-i). Втім, розглядаті останню технологію ми не будемо, оскількі по суті своїй вона практично повністю аналогічна VT-x. Нагадаємо, що раніше дана технологія була відома під кодовими іменамі Vanderpool (для персональних компютерів) і Silvervale (для серверів).

Що ж зробила Intel? Досить нетрівіальну, Хоча і напрошуються річ. Розробник архітектури IA-32 просто ввела в своїх процесора СПЕЦІАЛЬНИЙ «режим виконання віртуальної машини» (Virtual Machine eXecution mode, VMX), призначений спеціально для віртуалізаційніх ПЗ (Virtual Machine Manager, VMM), і визначена для ЦЬОГО режиму Кілька Ключовий «віртуалізаційніх» інструкцій, таких як, пріміром, «створити віртуальний компютер» і «запустіті віртуальний компютер». Власне цей самий «віртуальний компютер» в VT-x опісується спеціальної структурою під назв VMCS (Virtual Machine Control Structure) і по суті своїй є невелика ділянкою фізичної оператівної памяті, що зберігають мінімально необхідні Дані для запуску гостьової операційної системи, а такоже Дані, необхідні для безпечного виходить з режиму роботи гостьової ОС, і Деякі налаштування, повязані з Керування цією віртуальною машиною.

Програміст практично вручну створює цю структуру, повністю опісує необхідній Йому віртуальний компютер та його Властивості, ПІСЛЯ чого «завантажує» Її в СПЕЦІАЛЬНИЙ апаратний регістр «поточної віртуальної машини». Потім програміст може «запустіті» свіжоствореній віртуальну машину спеціальною інструкцією.

Схема 7. Віртуалізація з використанням VT-x.

Запущена Віртуальна машина працює на звичайних апаратних ресурсах компютера (зазначених VMM в опісі віртуальної машини) і для запущеного на ній програмного забезпечення практично нічим НЕ відрізняється від звічайної «фізічною» машини. Але на відміну від «Звичайний» режиму, в цю віртуальну машину можна вставляті як завгодно багато «закладок», ЯКІ будуть переріваті Її виконання, передавальних управління тому до VMM, Який буде вручну імітуваті ту чи іншу подію, або виконання тієї або іншої Інструкції. Які саме події будуть перекідатіся для «ручної обробки» VMM, визначається Тільки самим програмістом, але ЇХ в будь-якому випадку Навіть Більше, Ніж Необхідно для реалізації як завгодно складної віртуальної машини, аж до точної імітації Зовсім іншого процесора. Пріміром, проблемною у звичайно випадках операція читання-запису регістра CR3 в VT-x просто призведе до того, що процесор на секундочку призупинили гостьова ОС, вікліче VMM, Який програмно сімітірует результат Її виконання (не віконуючі справжня інструкцію MOV to / from CR3 з апаратний регістром, а підмінівші Її читанням-записом звичайно шматочка оператівної памяті), ПІСЛЯ чого відновіть виконання гостьовій ОС, яка «каверзи» Навіть не відчує.

При бажанні можна Навіть вручну «підкручування» Лічильник тактів процесора і Свідчення системного таймера, Щоб у гостьовій ОС не виникла сумнівів непотрібніх, з приводу того, з чого це раптом Деякі Інструкції на даному «процесорі» виконуються так довго. Можна Навіть спробувати один-в-один зімітуваті AMD Athlon XP на Intel Pentium 4 - так, що програмне забезпечення «Гостьовий» операційної системи не буде і здогадуватіся про підміну. Правда, Якщо бути точним Зовсім, то оскількі Pentium 4 не підтрімує набір інструкцій AMD 3Dnow, А технологія VT-x НЕ дозволяє перехоплюваті помилки типу «невідома інструкція» (Invalid Opcode), то зімітуваті підтримку 3Dnow! на P4 неможливим. Але 3Dnow! все одно сьогодні практичність не вікорістовується, а в усьому іншому (скажімо, у всьому тому, що рапортує про процесор стандартна інструкція CPUID), імітованім компютер буде вести себе точно як AMD Athlon XP, так що переважно більшість ПЗ на «віверт» піддасться.

От і вся технологія віртуалізації VT-x - ми просто перекладається наш процесор в такий режим, коли ВІН перехоплює Деякі (визначені нами) події і передає ЇХ у спеціальну програму - менеджер віртуальної машини. І ніякої складної бінарної трансляції!

Всього в VT-x десять нових інструкцій:

· VMXON і VMXOFF включаються і вимикають режим VMX.

· VMWRITE дозволяє програмісту запісуваті Дані в структуру VMCS, що опісує віртуальну машину; VMREAD - аналогічно читать Дані з VMCS. Власне формат структури VMCS офіційно невідомий, і яким чином і що там, взагалі кажучи, зберігається - одна Intel знає. Зауважімо, такоже, що сама структура VMCS відносно невелика за розмірамі (одиниці кілобайт) і не зберігає в собі, пріміром, даних про віртуальну памяті, що утворює фізічну память «віртуального компютера», - ЦІ Дані менеджер VMM підтрімує (завантажує і зберігає) для віртуальніх машин самостійно.

· VMPTRLD дозволяє вібрато потоково віртуальну машину (покажчик на VMCS). VMPTRST, аналогічно, ЗБЕРЕГТИ покажчик на поточно віртуальну машину.

· VMLAUNCH дозволяє запустіті вибране віртуальну машину (опісується раніше встановлених Покажчик на коректно потоково VMCS).

· Виконання коду працює віртуальної машини переріває або настання зазначених у VMCS події (зовнішнього переривані, спроба ВИКОНАТИ ту чи іншу інструкцію), або виконання Інструкції VMCALL (Якщо вона дозволена в настройках VMCS).

· VMRESUME дозволяє продовжіті перерване подією виконання коду на віртуальній машіні.

· VMCLEAR вікорістовується для ініціалізації порожній структури VMCS і для перекладу вібраної віртуальної машини в «зупинення» табору (зі збереженням даних VMCS).

Схема 8. Набор инструкций VT-x

Доступ до інструкцій VT-x за замовчуванням заблокований; для їх включення потрібно «включити» біт 4 в четвертому контрольному регістрі процесора (CR4.VMXE = 1) і «включити» біти 0 і 2 в MSR-регістрі 3Ah. На віртуальній машині, емульованої за допомогою VT-x, можна замаскувати підтримку VT-x, повідомляємо інструкцією CPUID, і примусово заблокувати будь-яку можливість використання у віртуальній машині інструкцій даного сімейства. З урахуванням можливостей по маскуванню виконавчі інструкцій на віртуальній машині це означає, що можна домогтися того, що виконуються на віртуальній машині програмне забезпечення ні за яких умов не зможе здогадатися про те, що працює не на реальному компютері, а на віртуальній машині.

Технологія Intel VT вже вийшла на ринок - у продажу є як настільні, так і серверні процесори, офіційно її підтримують. Перелік процесорів Intel з підтримкою VT постійно поповнюється, і ви без праці зможете знайти його на сайті Intel разом із популярним описом самої технології. Корпорація для популяризації цього свого рішення любить влаштовувати живі демонстрації можливостей технології віртуалізації, коли спершу «типовий професіонал» сидить поруч з чотирма системними блоками (пофарбованими для наочності у різний колір), один з яких вважає професійну задачу, на другий виконується офісна робота, третій « крутить »невеликий сервер, четвертий займається обслуговуванням та антивірусної перевіркою (усі - під різними ОС). І кожну з цих систем можна незалежно «підвісити», «заразити» або перезавантажити, в той час як інші продовжують свою діяльність. І кульмінацією цієї демонстрації стає момент, коли відкриваються кришки цих системних блоків, а під ними - порожньо. Поряд ж коштує звичайний «непримітний» системний блок (для наочності пофарбований у ці ж 4 кольори - в смужку), який лише і виконує всю описану вище роботу - під управлінням Intel VT з апаратною підтримкою і декількома одночасно працюють ОС. На недосвідчених користувачів така демонстрація надає велике враження.

Другий, більш «побутової» демонстрацій Intel VT зазвичай виступає домашній мультимедійний компютер, який одночасно обслуговує декілька незалежних користувачів, таких як тато працює з поштою, мама дивиться фільм, а дитя - так, грає чи слухає музику. Папа закінчив і вимкнув свою систему (або система сина під час гри підвисла і пішла на перезавантаження), але при цьому інші користувачі продовжують роботу / розвага, як ні в чому не бувало. Нарешті, принципи віртуалізації використовуються і в деяких «профільних» рішеннях для певних регіонів ринку. Наприклад, в знаменитому «китайському» домашньому концепт-ПК від Intel, який легким поворотом ключика може перекладатися з режиму роботи звичайної користувацької ОС в спеціальний навчальний режим з графічним сенсорним екраном, призначений тільки для простори освоєння ієрогліфічного письма. При цьому поточний стан звичайної ОС повністю зберігається, і до нього можна легко повернутися зворотним поворотом ключика.

Загалом, простір для застосовності технологій віртуалізації на роботі і в побуті є, і питання його грамотного використання з новітніми процесорами Intel тепер лягає на плечі відповідного програмного забезпечення, яке поки що не отримало широкого розповсюдження. Хоча, будемо сподіватися, скоро його все ж таки отримає.

а) Віртуалізація завтра: AMD Secure Virtual Machine «Pacifica»

З AMD ситуація ще цікавіше: в 2005 році ця компанія сильно здивувала світову громадськість, випустивши свою технологію віртуалізації, абсолютно несумісну з технологією, запропонованою Intel. Ось так! Раніше процесори Intel і AMD працювали на одних і тих самих материнських платах, потім стали працювати на різних, потім вимагали різних типів оперативної памяті, а тепер ось - і різного програмного забезпечення. Можете навіть не намагатися встановити віртуалізаційних софт «для Intel» на процесори AMD - там немає нічого навіть близько схожого.

Щоправда, з іншого боку, рішення AMD більш досконалий і більш сучасним. А несумісність концептуальних підходів виявляється лише у відносно невеликої частини коду модуля VMM (будь-які операційні системи і звичайне ПЗ, природно, будуть як і раніше однаково добре працювати на процесорах і Intel, і AMD). Але - тим не менш.

Давайте на хвилинку повернемося до Intel і подивимося на те, який підхід був покладений в основу ідеології VT-x. У нас є якась «базова» операційна система, в якій користувач запускає програму типу VMWare Workstation або Microsoft VirtualPC, а вже цю програму при бажанні може підкрутити щось в процесорі, включити режим віртуалізації, створити спеціальний модуль з управління віртуальними машинами, створити віртуальні машини, і запустити на них якісь «гостьові» операційні системи зі своїми додатками. При цьому «режим VMX» не є чимось дуже особливим і запущений в цьому режимі код ніякими особливими привілеями не володіє. Фактично це просто звичайна програма (або драйвер), запущене на процесорі і має зайвої парою прапорців, записаних глибоко в службових регістрах процесора.

У AMD підхід принципово інший, більш простий і наочний. Починається він теж з менеджера віртуальних машин VMM, та тільки ось менеджер той на інтеловськіх аналог абсолютно не походить. У Intel VMM - це якесь дуже хитре додаток звичайної операційної системи, яке може бути запущено навіть з кільця звичайного пріоритету. У AMD - це системний код, що працює на більш низькому рівні, ніж сама операційна система, і запускається виключно з системного Ring 0. Модуль VMM в Pacifica фактично виконує роль ядра деякої «базової» операційної системи, і тільки цей код в Pacifica працює з власне фізичним обладнанням. Усі «звичайні» операційні системи в підході AMD - гостьові і працюють з віртуальними машинами, які для них створює VMM. Оцініть всю принадність рішення: у Intel модуль VMM в поті чола займається «фальсифікацією» купи різних подій, вибиваючись з сил, аби зробити вигляд, що гостьова ОС працює з реальним «залізом». У AMD модуль VMM просто один-єдиний раз створює віртуальну машину, перемикається в «гостьовій режим» - і запущений в цій гостьовій машині код працює з свіжостворений віртуальною машиною в практично повністю автономному режимі, без будь-якого втручання VMM.

Схема 9. Віртуалізація з AMD Pacifica

Як таке можливо? Та дуже просто: AMD дійсно віртуалізується фізичні ресурси, і, перш за все, - оперативну память. «Фізична» віртуальна память, видима гостьовими ОС в Pacifica - це просто віртуальна память другого рівня. Таблиці трансляції для якого контролює, природно, VMM. Тобто якщо яка-небудь програма, запущена в цій гостьовій ОС, скажімо, звертається до памяті за адресою такому-то, то процесор, використовуючи таблиці трансляції, контрольовані гостьовій ОС, спочатку перетворює цю адресу в «фізичний» адреса, який вже апаратно, без участі VMM перетвориться в справжній фізичну адресу. Або, як уже говорилося, не перетворюється, а викликає підкачування з своп-файлу, завантаження даних по мережі, і інше - можливості віртуальної памяті в умілих руках безмежні. VMM, до речі кажучи, влаштований набагато простіше операційної системи, повністю незалежний від неї, і тому потенційно можливо реалізовувати на його основі всю ту «рідкісну» функціональність, яку зазвичай не ризикують (або не хочуть) вносити до ядра звичайних операційних систем.

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

З просто-таки напрошуються прикладів - можна, приміром, буде створити такий компютер, на якому мають виконуватися тільки ліцензійні операційні системи виробництва Microsoft без єдиного байти «чужих» змін з боку любителів халявного ПЗ. Вірніше сказати, запускати на цьому компютері, при бажанні (скажімо, після перепрошивання BIOS) можна буде, звичайно, все що завгодно, але при цьому в процесорі не взведется спеціальний «біт безпеки», легко перевіряється абсолютно будь-яким додатком, і з подібним «не минулим перевірку »компютером, наприклад, може відмовитися працювати яке-небудь ПЗ. Для звичайного користувача, боюся, подібна можливість виллється в чергову купу проблем з копірайтом і вільним софтом, однак для корпоративних користувачів підтримка «безпечного режиму» може виявитися життєво важливою, оскільки дозволяє гарантувати безпеку середовища, в якій запускається корпоративне додаток. Перевірив «безпечний прапор» - означає компютер гарантовано «чистий», «перевірений». Немає цього прапора - значить, в системі щось змінилося: поміняли частина «заліза» (поміняли клавіатуру, на що містить «жучок»; додали шпигунську PCI-плату, що збирає інформацію про ПЗ; поставили чужу мережеву карту; посадили в систему «руткіт» і так далі). Крім того, в захищеному режимі процесор може автоматично знищувати не використовувані більш дані з памяті (зокрема, при перезавантаженні системи), гарантуючи відсутність витоків «сміття», що залишається після роботи додатків в «чужі» руки. А оскільки підвищена безпека - одна з основних застосувань майбутніх технологій віртуалізації, то це ще один величезний плюс технології AMD.

Втім, справедливості заради, треба відзначити, що в Intel розробляється (вже протягом декількох років) власна технологія апаратного безпеки під назвою LaGrande, яка вміє дуже багато що і навіть більш готова до виходу на ринок, ніж Pacifica. Так що, цілком можливо, що звязка Intel VT + LaGrande виявиться не менш функціонально привабливою, ніж AMD Pacifica. А вже в умінні Intel влаштувати грамотний і широкомасштабний маркетинг своїх продуктів сумніватися не доводиться.

Саме по собі функціонування VMM у AMD дуже нагадує функціонування VMM в технології Intel: VMM за допомогою спеціальних інструкцій готує спеціальні керуючі структури, що описують віртуальні компютери, «запускає» ці структури на виконання і перехоплює вибрані події, що відбуваються там, підміняючи їх «ручний» роботою. Головна відмінність - це обсяг і тип виконуваної роботи. У AMD немає необхідності займатися складним менеджментом памяті з підставними таблицями трансляції та синхронізацією цих таблиць з справжніми, нема необхідності у перехопленні повязаних з цими таблицями трансляції подій. Потрібно перехоплювати і обробляти тільки деякі зовнішні події (скажімо, переривання від таймера, щоб перемикаючись між гостьовими операційними системами створювати ілюзію їх одночасної роботи; або переривання від клавіатури - перемикатися між гостьовими ОС по натисненню певної комбінації клавіш). Та й то, при бажанні в Pacifica можна просто «напряму» підключити вибрані пристрою в гостьових операційних системах до фізичних ресурсів (у VT-x, для порівняння, будь-яке звернення гостьовій ОС до портів введення-виведення примусово перехоплюється модулем VMM).

Є й інші особливості, що дозволяють мінімізувати кількість непотрібних переключень від гостьової ОС до VMM і назад, переклавши відповідні перевірки на апаратне забезпечення. А якщо і доводиться все-таки перемикатися між гостьовій ОС, VMM, та іншої гостьової ОС - то, знову ж таки за контрастом з VT-x, це переключення відбувається украй швидко, з дуже обмеженою необхідністю у збереженні контексту і повною відсутністю необхідності скидання, приміром, буфера TLB, який зазвичай під час переходу між різними таблицями трансляції доводиться повністю очищати. Природно, що набір перехоплюваних подій і можливості «фальсифікації» усього й вся нітрохи у Pacifica не вже, ніж у VT-x; проте настройка що перехоплювати, а що ні - набагато гнучкіша (у VT-x багато перехоплюється безумовно; в Pacifica можна відключити практично будь-який перехоплення). Навіть не знаємо, до чого причепитися, - навряд чи можна було придумати щось більше за функціональністю, зручне у використанні, і настільки швидкодіюче.

Набір інструкцій Pacifica настільки ж простий і витончений, як і саме рішення AMD:

· Команда VMRUN перемикає виконання на обрану віртуальну машину.

· З віртуальної машини управління повертається або з перехоплення одного із зазначеного в налаштуваннях віртуальної машини подій, або при виклику спеціальної інструкції VMMCALL (якщо остання дозволена налаштуваннями).

· Інформація про віртуальній машині зберігається в спеціальній структурі даних VMCB (Virtual Machine Control Block) відомого формату. VMM працює з даною структурою безпосередньо, вручну змінюючи при необхідності відповідні поля (на відміну від VT-x, де формат аналогічної структури VMCS офіційно невідомий і для роботи з VMCS використовуються спеціальні інструкції VMREAD і VMWRITE). Про всяк випадок ще раз нагадаємо, що сама ця структура відносно невелика і описує тільки стан процесора віртуальної машини, а віртуальну память і стан віртуальних пристроїв цієї машини VMM повинна обслуговувати самостійно.

· Найбільш необхідні операції з переключення контексту при переходах VMM до гостьової ОС і назад виконуються повністю автоматично. Проте, щоб не робити зайвих дій, зберігається і завантажується дійсно тільки найнеобхідніше, і при необхідності будь-яких складних дій або перемикання на іншу гостьову ОС, «додаткові» операції збереження стану процесора в VMCB і зворотного завантаження виконуються інструкціями VMLOAD і VMSAVE.

· Інструкція SKINIT дозволяє почати завантаження процесора в «безпечному режимі», на апаратному рівні гарантувавши відповідність завантажувача (до 64 Кбайт коду) зазначеної в апаратурі (в модулі TPM) цифрового підпису

Пять інструкцій. Проти десяти в куди більш складному і менш функціональному VT-x. Ну як ще висловити захоплення архітекторами наборів інструкцій AMD? Щоправда, до «пяти базових» для повного розкриття можливостей Pacifica можна ще використовувати «тактичні» три інструкції, що дозволяють додатково прискорити швидкість роботи Pacifica:

STGI, CLGI - управляють схемою перехоплення переривань в Pacifica (включають-вимикають «глобальний перехоплення переривань»).

INVLPGA - скидає TLB, але не цілком, а тільки ті записи TLB, які відносяться до конкретної гостьовій ОС (або до VMM).

Схема 10. Набір інструкцій Pacifica

Як і у випадку з VT-х, для того, щоб отримати доступ до нових інструкцій, програмного забезпечення потрібно ці інструкції розблокувати (встановити 12-й біт регістра EFER MSR, відтепер відомий як EFER.SVME). При бажанні в Пасифік можна відключити всі її просунуті функції, аж до відключення подвійний трансляції віртуальних адрес, що дозволяє максимально наблизити (хоча і не до кінця) схеми використання до VT-х.

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

Цікаво, що на останньому московському Intel Developer Forum (що пройшов у жовтні 2005 року) в доповідях абсолютно несподівано прозвучали все ті ж знайомі «подвійні таблиці трансляції», «захист DMA» та інші характерні функції Pacifica, рекламувалися як... друге покоління систем віртуалізації Intel. До першого, природно, ставилася «закриває дірки x86 технологія VT-х. Чесно кажучи, сам московський ІСО з нашою субєктивної точки зору, опинився в плані інформації з віртуалізації вкрай скупий, а рівень «пізнань» заміняли своїх іноземних колег співробітників, які виступали з доповідями часом просто шокував - вони були не в змозі відповідати на задаються їм із залу неспеціалістами питання! Але пізніше чудовий чоловік - Всеволод Предтеченський, поодинці замінює всіх інших технічних фахівців російського відділення Intel - в особистій бесіді пояснив, що цим самим «другим поколінням» повинна стати давним-давно анонсована «технологія безпеки» LaGrande (а вірніше, те, у що цей проект перетворився до теперішнього часу), яка вбере в себе не тільки новітні технології віртуалізації (про які ми поговоримо в останній частині), але й складні системи забезпечення гарантованої безпеки (аж до шифрування переданих по USB даних мишкою).

3. Інші підходи до віртуалізації. Віртуальна машина Xen

Проект Xen (вимовляється як «Зен») - мабуть, самий динамічно розвивається і сучасний пакет віртуалізаційних ПЗ, яскравий приклад того, на що, за відповідної підтримки, здатне співтовариство Open Source. Започаткований Кембріджський університети як відкрита реалізація відносно нескладною технології паравіртуалізаціі, Xen незабаром став одним з найбільш популярних віртуалізаційних проектів, і отримав багатющу функціональність, що включає в себе систему забезпечення взаємної безпеки віртуальних машин, систему управління їх ресурсами, систему забезпечення «гарантованого рівня обслуговування» (якості обслуговування, QoS), систему «непомітною міграції» (за 50-300 мс можливо «перекинути» працюючу віртуальну систему з одного фізичного компютера на інший), і багато іншого. Як і будь-яке інше програмне забезпечення, що реалізує технологію паравіртуалізаціі, Xen виступав як прошарку між операційними системами та фізичним обладнанням, і вимагав, щоб операційна система була адаптована до роботи не з реальним «залізом», а з цієї віртуалізаційних прошарком. Відповідні патчі, що забезпечують необхідну підтримку для Xen з боку операційної системи були розроблені для Linux, FreeBSD, NetBSD і екзотичної Plan 9, і багато великих вендори включили цю підтримку, разом з самим Xen, в свої дистрибутиви відповідних операційних систем. І все це - за два роки, з 2003 по 2005 рік!

Схема 11. Віртуальна машина Xen

Наступний етап розвитку проекту був повязаний з імям Intel, яка вирішила використовувати Xen як основного «популяризатора» своєї технології віртуалізації VT. Розробники Intel дописали для Xen відповідний модуль, що забезпечує сполучення на VT-сумісних процесорах довільній ОС з внутрішнім інтерфейсом Xen. Модуль був включений в спільний проект, і таким чином Xen «несподівано» знайшов здатність працювати з довільними операційними системами - благо, що вся необхідна для цього інфраструктура в проекті вже була присутня. AMD, теж не залишилася осторонь, від цього питання, і до теперішнього моменту Xen отримав експериментальну підтримку і технології апаратної віртуалізації Pacifica, ще не «включення» ні в одному з продаваних нині процесорів AMD, але зате більш сучасною та зручною з точки зору реалізації. А оскільки «батьківського» операційної системи для Xen не потрібно, то ось так, відразу, з іграшки спільноти Open Source, цей проект перетворився на безкоштовний універсальний менеджер віртуальних машин для новітніх процесорів AMD Intel і, придатний для використання широким колом користувачів. Швидше за все, завдяки активній підтримці обох «грандів процесоробудування», саме Xen, а не продукція Microsoft або VMWare, ляже в основу майбутнього стандарту на VMM і стане «традиційним вибором користувачів». На жаль, станеться це, схоже, у порівняно віддаленому майбутньому, бо встановити, налаштувати, і змусити як-то працювати Xen прямо зараз зможе, боюся, далеко не кожен навіть досить досвідчений користувач.

Схема 12. XenSE: поліпшення безпеки віртуальних систем

Технічні характеристики Xen виглядають наступним чином: підтримуються всі спеціально адаптовані до Xen операційні системи, або будь-які x86-сумісні операційні системи (Itanium-сумісні - у стадії бета-версії Xen) за наявності коштів апаратної підтримки віртуалізації (Intel VT-х «Вандерпул» / AMD SVM «Пасифік»). На момент написання статті (Xen 3) для встановлення Xen-а було потрібно наявність працює версії Linux з завантажувачем GRUB, а конфігурація проводилася річний правкою конфігураційних файлів; причому Xen включав в себе самостійне ядро Linux, завантажувати в цій «рідний» системі замість основного, що, приміром, могло зажадати перекомпіляції для цього ядра наявних у системі модулів LKM. Для дистрибутивів, в які Xen спочатку був включений, особливої проблеми подібне своєрідність установки не створить (у SuSe Linux Professional 1910 управління Xen-му було навіть включено в графічну утиліту YAST Центр управління), всім іншим - доведеться чекати виходу відповідних придатних до використання звичайним користувачем пакетів. Правда, на жаль, навіть тоді серйозно запустити на платформі Xen операційну систему MS Windows вдасться лише з великим скрипом - надаються Xen можливості з імітування обладнання віртуального компютера сьогодні, мяко кажучи, недорозвинені, а працювати з мережевого протоколу з-під Linux із запущеною де- то там, в глибинах компютера, MS Windows, доступної хіба що у вигляді віртуального мережевого хоста, на якому з «заліза» присутній лише жорсткий диск, процесор, оперативна память, та мережева картка, завдання не з тривіальних. Юніксоіда такий набір влаштує цілком, «домашнього користувача» - навряд чи.

Проте це навряд чи сильно зашкодить світлого майбутнього Xen: з драйверами Intel і AMD проекту напевно посприяють, а поява зручного для кінцевого користувача дистрибутива, встановлюваного на «голу» або навіть вже працюючу машину - це лише питання часу. Почекаємо ближче до кінця 2006 року Xen версії 4?

Таблиця 1. Операційні системи Xen.

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 з відкритим кодом, і все це різноманіття буде чудово, без сьогоднішніх проблем з драйверами для різних ОС, одночасно в повну силу працювати.

Скачать архив с текстом документа