Спіралі апаратної віртуалізації

1. Біля витоків
2. x86
3. На шляху до апаратної віртуалізації
4. Модифікація системи команд
5. пам'ять
6. зовнішні пристрої
7. Застосування апаратної віртуалізації

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

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

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

Сучасні сервери набагато дешевше і потужніше машин десяти- і тим більше двадцятирічної давності, проте сукупні витрати на їх обслуговування, підтримку та адміністрування залишилися високими. Загальне прагнення, з одного боку, до консолідації ІТ-ресурсів, а з іншого - до їх повсюдного, безперервному і безпечного споживання стали новими двигунами розвитку технологій віртуалізації (за даними IDC, якщо в 2005 році засобами віртуалізації було оснащено 276 тис. Серверів, то до 2009-го їх число може досягти 1,1 млн.), але вже на новій процесорної платформі.

Ще за часів мікропроцесора Intel 80386 існувала програма-монітор віртуальних машин VM / 386, а також особливий режим V8086 для цього процесора, але все це було призначене тільки для запуску сеансів DOS. Реально ж працювати з різними операційними системами стало можливим тільки завдяки програмним рішенням VMware і інших розробників: архітектура і система команд процесорів x86 була орієнтована на віртуалізацію. І тому цілком природно, що сьогодні в віртуалізаційних «гонку» поспішили включитися і Intel і AMD, спочатку запропонували свої розширення архітектури, а потім включили кошти апаратної підтримки віртуалізації в мікропроцесори.

Біля витоків

Компанія IBM приступила до розробки перших віртуальних машин в 60-х роках, і віртуальна машина розглядалася тоді як повністю захищена і ізольована копія ресурсів фізичної машини, в якій додатки і операційні системи будуть вести себе точно так само як, і на реальних апаратних засобах. Управління гостьовими системами повинен був взяти на себе монітор віртуальних машин, який забезпечував віртуалізацію процесора, пам'яті і пристроїв введення-виведення, а також ізоляцію програм. Вперше для серійної системи повна віртуалізація була реалізована в програмі CP 67 на машині IBM System 360/67. Кожному користувачеві або розділу надавався точний віртуальний образ апаратних ресурсів фізичної машини і забезпечувалася робота в режимі поділу часу. Однак продуктивність CP 67 виявилася недостатньою, і було вирішено вбудувати засоби апаратної підтримки віртуалізації безпосередньо в архітектуру нового сімейства IBM System 370. Було відомо, що, коли гостьова система виконується безпосередньо на реальному процесорі і намагається виконати привілейовану команду, процесор повинен перервати роботу і передати управління монітора віртуальних машин, який і повинен вирішити, чи можна виконати таку команду або необхідно змоделювати її виконання іншими засобами.

Для машин IBM System 370 була розроблена OC VM / 370 (монітор віртуальних машин), яка працювала в розширеній архітектурі 370-XA, що має спеціальні апаратні засоби (assists, помічники або прискорювачі), які брали на себе істотну частину роботи монітора з перехоплення і емуляції потенційно небезпечних команд. Передбачався особливий режим роботи процесора (interpretive execution), для входу в який служила привілейована команда SIE (Start Interpretive Execution), разом з якою передавалося поточний стан гостьової системи. При завершенні режиму інтерпретації відповідним чином коректувалося слово стану програми PSW [ 1 ].

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

Наступним кроком стало створення архітектури віртуальних машин для корпоративних систем VM / ESA, в якій підтримувати середовище System / 370, ESA / 390, VM Data Spaces, 370-XA і ESA / 370, що було обумовлено високою вартістю обладнання та необхідністю міграції програмного забезпечення. Механізми управління пам'яттю отримали засіб Multiple Domain Facility (MDF), що дозволяло виділяти гостьовим системам окремі безперервні області пам'яті і більш ефективно перетворювати адреси пам'яті.

На віртуальних системах IBM VM були відпрацьовані ідеї і технології, багато в чому визначили архітектури сучасних рішень по віртуалізації не тільки для сучасних «мейнфреймів» IBM System z9 і систем на платформі Power, але і для систем на базі мікропроцесорів AMD і Intel.

x86

Як вже говорилося, при розробці архітектури x86 вимоги віртуалізації не враховувалися, і це підтверджується наявністю невеликого набору команд, які хоча і не є привілейованими, але можуть серйозно порушити стабільну роботу всієї системи. В умовах роботи з однієї ОС, для якої спочатку і створювалися ці процесори, ця обставина не викликає ніяких труднощів, але в віртуальній системі воно стає джерелом серйозних проблем. Відкритість - великий плюс архітектури x86, завдяки якій тисячі незалежних розробників створили безліч різних зовнішніх пристроїв і драйверів. Однак таке розмаїття стримує вирішення завдань віртуалізації. Проте зусиллями дослідників і фахівців VMware, Microsoft, XenSource і співдружності незалежних розробників багато недоліків платформи x86 з точки зору віртуалізації вдалося компенсувати на програмному рівні, причому загальним ключем до вирішення є наступний алгоритм [ 2 ]:

• безпечні, непривілейованих команди можна виконувати безпосередньо на процесорі;

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

• небезпечні непривілейованих команди необхідно виявляти, проте в системі команд x86 є 17 «проблемних» команд, надзвичайно чутливих до віртуального контексту, і їх не можна перехопити. Монітор віртуальних машин повинен контролювати роботу віртуальної машини і не допускати, щоб вона виконала такі команди.

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

На шляху до апаратної віртуалізації

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

Модифікація системи команд

Власні рішення AMD V [ 3 ] і Intel VT в 2005 - 2006 рр. запропонували обидва виробники.

Intel VT. Підтримка віртуалізації за версією Intel забезпечується особливим режимом VMX процесора. Монітор віртуальних машин виконується в привілейованому режимі VMX root, а гостьова ОС з меншими привілеями - в режимі VMX non-root. Обидва режими підтримують виконання на всіх чотирьох рівнях (кільцях) повноважень ( Мал. 1 ). Вхід в віртуальну машину відбувається по команді VMRUN, а зворотний перехід може бути як умовним (зміна певних розрядів регістра), так і безумовним (команда скидання кеш-пам'яті). Це і визначає основна відмінність режимів VMX root і VMX non-root - виконання небезпечних команд призводить до виходу з віртуальної машини. Стан процесора відстежується за допомогою особливої ​​структури даних VMCS, що містить області управління виконанням віртуальної машини (VM-execution control fields), що задають умови виходу з віртуальної машини. Важливо швидко визначити ці умови, вжити необхідних заходів і повернути управління гостьовий системі. Механізм двосторонньої взаємодії дозволяє монітору віртуальних машин не тільки реагувати, але й ініціювати переривання і виключення в віртуальній машині.

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

Компанія Intel розвиває також технологію апаратної підтримки захисту LaGrande, що охоплює процесор, набір мікросхем, апаратний модуль безпеки TPM (Trusted Platform Module) і захищений введення / виведення.

AMD-V. Функціональність рішення від компанії AMD базується на розширенні технології AMD Direct Connect і близька по можливостях Intel VT, однак розширення архітектури системи команд виявилися несумісними. У рішення AMD підтримка механізмів управління пам'яттю MMU і DMA закладалася спочатку (мікропроцесори AMD вже були оснащені шиною HyperTransport і контролером DMA), що створювало певні «ідеологічні» переваги до тих пір, поки Intel не оприлюднила власні специфікації перетворень для DMA.

Мал. 2. У AMD-V Введення гостьовий режим, керуючий блок і додаткові команди

Віртуалізація в AMD-V реалізується шляхом введення гостьового режиму процесора Guest Mode, керуючої структури даних VMCB (Virtual Machine Control Block) і додаткових команд (рис. 2).

Для прискорення обробки введені дворівневі таблиці трансляції адрес віртуальної пам'яті, а завдяки підтримці віртуалізації контролером забезпечується захист адресного простору віртуальних машин. Застосування індексів при трансляції віртуальних адрес (tagged TLB) дозволяє оптимізувати процес їх перетворення. При обміні даними з зовнішніми пристроями діє апаратний захист контролера DMA, а за допомогою модуля безпеки TPM реалізується безпечний запуск віртуальної машини.

Технології апаратної віртуалізації AMD-V і Intel VT відкривають для компаній і незалежних розробників можливість створення ефективних моніторів віртуальних машин, що підтримують різні гостьові ОС без їх модифікації.

пам'ять

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

Отже, перед розробниками стояло наступне завдання - забезпечити апаратну підтримку віртуалізації блоку управління пам'яттю (MMU). Компанія Intel запропонувала розширені таблиці сторінок (extended page tables, EPT), а AMD - вкладені таблиці сторінок (nested page tables, NPT). Основна ідея полягає в тому, щоб зняти з монітора віртуальних машин частина навантаження з підтримки цілісності відображень тіньових таблиць. Для цього, наприклад, в технології EPT, вводиться окремий набір таблиць сторінок, які підтримуються на апаратному рівні і встановлюють відповідність фізичних адрес гостьовий і головною системи. Таким чином, завдяки апаратній підтримці, відпадає необхідність постійного перемикання між віртуальною машиною і монітором, що в сумі є дуже «дорогої» операцією.

Інше завдання - прискорення доступу до буфера швидкого перетворення адрес (TLB). Для цього в компанії Intel запропонували поставити у відповідність кожній віртуальній машині ідентифікатор віртуального процесора (virtual processor identifier, VPID). В технології AMD застосовується ідентифікатор адресного простору (address space identifier, ASID). Якщо забезпечити такими «ключами» Рядок TLB, то можна уникнути скидання буфера при кожному вході і виході з віртуальної машини.

зовнішні пристрої

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

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

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

Підтримка апаратних ЗАСОБІВ с помощью драйверів потрібна для организации ефективних операцій віртуального Введення-Виведення, проти вбудовування великого числа драйверів в монітор віртуальніх машин может віявітіся Занадто дорогим підпріємством. У тій же година использование спеціальної віртуальної машини для управління ресурсами зовнішніх прістроїв пов'язане з Додатковий накладними витратами продуктівності. У зв'язку з цим було запропоновано три моделі (архітектурні схеми) віртуалізації пристроїв введення-виведення ( Мал. 3 ).

Мал. 3. Моделі віртуалізації введення-виведення

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

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

Основна проблема, однак, полягає в тому, що реалізація прямого доступу безпосередньо до віртуальної пам'яті з боку пристроїв гостьової системи утруднена, оскільки вимагає неодноразово виконувати перетворення адрес і підтримувати ізоляцію програм. На вирішення цієї проблеми спрямовані пропозиції AMD і Intel по апаратній підтримці введення-виведення.

AMD IOMMU. Пропозиція AMD полягає в тому, щоб обробляти віртуальні операції введення-виведення за допомогою бітової матриці або вектора виключення пристроїв (device exclusion vector, DEV) - таблиці управління прямим доступом пристроїв до сторінок пам'яті гостьової системи. Якщо доступ дозволений, запит позначається як безпечний, і наступні перевірки не проводяться. Таким чином, виділене пристрій може отримати доступ тільки до відповідних сторінок пам'яті «своєї» гостьової системи.

Концепція DEV в специфікації AMD IOMMU розширена - тепер кожному пристрою може бути призначений специфічний домен і власний набір таблиць сторінок введення-виведення. При спробі читання або запису в системну пам'ять IOMMU перериває доступ, знаходить домен, який призначений пристрою, і по TLB визначає наявність дозволу доступу та фактична адреса, за якою слід звернутися до пам'яті.

Мал. 4. Реалізація розподіленої системи управління пам'яттю вводу-виводу

Факультативно можуть підтримуватися віддалені IOTLB - пристрої, що мають IOTLB, можуть взаємодіяти з IOMMU при перетворенні адрес, що дозволяє створювати масштабовані системи, в яких є пристрої з різними моделями використання (рис. 4). Локальні TLB відповідають специфіці пристроїв, і при цьому продуктивність останніх не обмежена кількістю записів TLB, реалізованих в IOMMU.

Intel VT-d. Основні компоненти цього рішення - кошти перетворення адрес DMA і віртуалізація переривань. Для цього була розширена архітектура модуля управління пам'яттю вводу-виводу IOMMU. Традиційно IOMMU застосовується при розподілі і збірці областей пам'яті і розміщується в мостах PCI root, а в специфікації VT-d передбачаються програмно визначаються домени (ізольовані області фізичної пам'яті основної системи), за допомогою яких доступ до пам'яті дозволяється тільки пристроїв, асоційованим з цим доменом. Даний механізм забезпечує ізоляцію і виключення пристроїв аналогічно DEV. Домени захисту можуть визначатися як для віртуальних машин, так і для драйверів пристроїв, що виконуються в моніторі віртуальних машин.

При використанні таблиць віртуальної адресації DVA забезпечується необхідний рівень ізоляції, оскільки доступ до фізичної пам'яті дозволяється тільки виділеним пристроїв. Для прискорення перегляду передбачається використання таблиці IOTLB, ключем якої служить тріада «шина PCI - пристрій - функція». Як тільки дані записані в пам'ять, гостьовий системі надсилається повідомлення. Зауважимо, що раніше переривання передавалися через монітор віртуальних машин, що викликало додаткові накладні витрати - зовнішній пристрій могло сигналізувати про переривання або за допомогою контролера, або через повідомлення MSI, що передається через DMA. Формат цього повідомлення в специфікації Intel VT-d перевизначений і забезпечує підвищений ступінь ізоляції. Операції запису DMA містять ідентифікатори повідомлення і запитує пристрою, і по ним індексується таблиця відображення переривань. Додаткові структури відображення можуть бути вкладеними, і для прискорення їх обробки передбачаються різні апаратні засоби, в тому числі IOTLB і кешування переривань. Специфікація забезпечує захищений і ефективний доступ виділених пристроїв до пам'яті віртуальних машин, проте, поділ високопродуктивних пристроїв поки не реалізовано. Компанія Intel виконала великий обсяг досліджень, і тепер роботи передані спільноті виробників пристроїв і робочій групі PCI Express Special Interest Group . Ефективність майбутніх рішень буде визначатися, з одного боку, розвитком функціональних можливостей власне процесорів і наборів мікросхем, а з іншого - вдосконаленням програмних реалізацій моніторів віртуальних машин по використанню коштів апаратної підтримки віртуалізації.

Застосування апаратної віртуалізації

Перехід до віртуальних технологій, підтримуваним апаратно, може бути обумовлений різними мотивами.

Ізоляція систем. Застосовується для забезпечення незалежності віртуальних машин. Гостьові ОС і додатки розподіляються залежно від їх критичності і функціональних можливостей. Наприклад, в центрі обробки даних мультисервісної телекомунікаційної системи компоненти системи інформаційної безпеки (мережеві екрани) і сервери, що підтримують обробку голосових повідомлень, розгортаються в гостьовій ОС Linux, а сервери потокової обробки даних - під керуванням Windows Server на єдиній апаратній платформі. Для забезпечення відмовостійкості гостьові ОС можуть дублюватися, і тим самим час простою в разі відмови може бути зведене до мінімуму.

Консолідація навантаження. Використовується для об'єднання фізичних серверів у вигляді окремих віртуальних машин, кожна з яких має власну операційну систему. При цьому єдиний адміністративний інтерфейс дозволяє організувати ефективне управління фізичними і віртуальними ресурсами. Динамічне виділення і перерозподіл ресурсів серверадает можливість швидко переміщати виконуються додатки, в залежності від робочих навантажень. Якщо раніше така можливість використовувалася переважно для забезпечення відмовостійкості, то тепер, в умовах надання ресурсів на вимогу (utility computing), вона стає однією з основних забезпечують технологій центрів обробки даних.

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

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

***

Сучасні технології апаратної підтримки віртуалізації: розширення архітектури та системи команд процесорів, управління доступом до пам'яті, віртуалізація зовнішніх пристроїв багато в чому реконструюють на час забуті рішення компанії IBM - родоначальниці віртуалізації взагалі і її апаратної підтримки. Зокрема (механізм вбудованих апаратних прискорювачів, режим інтерпретуючого виконання, Популярні на апаратному рівні ієрархічні тіньові таблиці сторінок). Сучасні постачальники мікропроцесорів йдуть далі, реалізуючи індексовані таблиці в блоці TLB, перетворення адрес і перерозподіл пам'яті для DMA, пропонуючи тонкі механізми взаємодії апаратних засобів і монітора віртуальних машин і відкриваючи спільноті розробників основні специфікації.

Сьогодні проблеми віртуалізації йдуть з області гіпервізора і моніторів віртуальних машин, в повній мірі використовують оновлені апаратні засоби. Черговий виток спіралі віртуалізації буде зроблений, коли ІТ-індустрія отримає нові операційні системи, здатні ефективним і безпечним чином надавати віртуалізовані ресурси в якості стандартних сервісів.

література

1. RJ Creasy, The Origin of the VM / 370 Time-Sharing System, IBM Journal of Research and Development, Volume 25, 1981.

2. JS Robin, CE Irvine. Analysis of the Intel Pentium Ability to Support a Secure Virtual Machine Monitor, USENIX Security Symposium, 2000..