Xreferat.com » Рефераты по информатике и программированию » Технології віртуалізації: вчора, сьогодні, завтра

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

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

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

Спосіб перший - це «спосіб свідомого співробітництва»: зводиться до того, що наші ОС будуть «враховувати інтереси» один одного, розподілять між собою апаратні ресурси, і надалі будуть працювати так, щоб не нашкодити своїми «надзвичайними повноваженнями» операційної системи іншій системі. Подібний підхід вельми широко практикується в * 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. А самі модулі від цього «довіреної джерела», у свою чергу можуть перевірити цифровий підпис у запускаються ними операційних систем; операційні системи - перевіряти цифровий підпис у запускаються додатків, і так далі, до як завгодно високих ступенів контролю того, що саме запущено на комп'ютері.

З просто-таки напрошуються прикладів - можна, приміром, буде створити такий

Если Вам нужна помощь с академической работой (курсовая, контрольная, диплом, реферат и т.д.), обратитесь к нашим специалистам. Более 90000 специалистов готовы Вам помочь.
Бесплатные корректировки и доработки. Бесплатная оценка стоимости работы.

Поможем написать работу на аналогичную тему

Получить выполненную работу или консультацию специалиста по вашему учебному проекту

Похожие рефераты: