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

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

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

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

На тему:

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

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

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

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

Краснодон

2009

Зміст

Вступ

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

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

VMWare Workstation і VMWare Server

Microsoft VirtualPC / Virtual Server

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

Віртуалізація завтра: 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 був скинутий»), визначає, що цією адресою відповідає сторінка пам'яті, якої немає в оперативній пам'яті, але яка є на жорсткому диску - і починає діяти:

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

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

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

Оновлює при необхідності дані в буфері 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-системах.

Як вихід із ситуації виникає цілком логічна пропозиція: якщо вже ми не можемо