Последната актуализация на този раздел е от 2021 година.

§ 6.4 Концепция за виртуална памет

Ще припомним, че разглеждаме йерархичната запомняща система отгоре надолу и тук идва редът на следващото ниво – нивото на външната памет. За “щастие” външната памет не е обект на нашето внимание тук. Единствената тема, която ще бъде изяснявана по-нататък, е свързана със структурата и организацията на така наречената виртуална памет. Външната памет ще бъде илюстрирана частично и дотолкова, доколкото е необходимо за това понятие, тъй като тя все пак задължително участва като елемент при физическото реализиране на виртуалната памет.

С появата на персоналните компютри и масовизацията на тяхното приложение основното препятствие пред бурното развитие на софтуерните системи се оказа оперативната памет. Не е необходимо да се връщаме във времето твърде назад, за да си припомним първите персонални компютри с техните операционни системи от класа на MS-DOS. На тези компютри не беше възможно да се зареди програма или масив с данни, превишаващи размера на оперативната памет. В още по-тежко положение се оказваха многозадачните или многопотребителските системи, защото несъответствието между обема на физическата оперативна памет и сложността на приложния софтуер нарастваше пропорционално с броя на задачите (потребителите). Решения на посочените проблеми започнаха да се появяват в края на 60-те години на миналия век. Първият частен метод, който беше практикуван бе програмирането с припокриване на кода (overlay). През 1972 са публикувани основните концепции за проектиране на системи с разделяне на времето. А през 1974 година списание “IBM Systems Journal” публикува подробно описание и анализ на главните механизми и тяхната реализация за напълно виртуална компютърна памет.

Развитието на методите за управление на паметта протича заедно с общата еволюция на компютърните системи. По-долу ще изложим кратко използваните структурни схеми за управление на паметта, тъй като заложените в тях основни идеи продължават да се прилагат.

Елементарни схеми за организация на паметта

1. Памет с фиксирани дялове

Една от най-тривиалните схеми за управление на паметта се постига чрез разделянето й на равни части с фиксиран обем, наричани дялове. Постъпващият от операционната система процес се зарежда в свободен дял. Свързването на логическите адреси с физическите се постига на етапа на зареждане на процеса в избрания за него конкретен дял. Понякога това се постига още на етапа компилация. Всеки дял от паметта може да има своя опашка от процеси, но може да съществува и глобална опашка за всички дялове.

Известни са 3 варианта за избор на дял при ново постъпил процес:

· Избор на първия подходящ (First fit). Процесът се зарежда в първия срещнат дял с достатъчен обем ;

· Избор на най-подходящия (Best fit). Процесът се зарежда в онзи дял, в който след зареждане на процеса ще остане най-малко свободно място ;

· Избор на най-малко подходящия (Worst fit). При този критерий, след зареждане на процеса в дяла остава достатъчно място за зареждане на още един процес.

След сравняване на трите варианта се твърди, че полезно използваната част от паметта в първите два случая е по-голяма, при това първият вариант осигурява малко по-голямо бързодействие.

Представения подход за менажиране на паметта има следните недостатъци:

· Броят на едновременно заредените процеси е ограничен до броя на дяловете ;

· Появява се вътрешно-дялова фрагментация. Това са части от паметта, отредени за процеса, но не използвани от него. Тази фрагментация възниква по причина на това, че процесът не заема целия обем на дяла или защото някои дялове са твърде малки за изпълняваните потребителски програми.

2. Памет с припокриваща се структура - (overlay)

Когато размерът на логическото адресно пространство на процеса е по-голям от този на заделения му дял в оперативната памет, се прилага техниката “с припокриване” (overlay). Основната идея се състои в това, че програмата може да се раздели на такива части, които задължително трябва да бъдат заредени в даден момент в паметта. Онези части, които според последователният ход на изчислителния процес се намират в състояние на очакване или са вече употребени, логично не следва да се задържат в паметта. Вероятно читателят вече разбира, че тук влиза в сила принципът на локалното действие.

Управлението на паметта при този подход изисква наличието на системен драйвер за зареждане на овърлеите. За описание на овърлейната структура на програмите се използва специален несложен език (overlay description language). Съвкупността от файлове използвани от заданието се допълва при това с файл. Който обикновено има разширението .odl. Този файл описва дървото на вътрешното извикване на овърлеите на програмата. При поредното зареждане на даден клон от програмата във физическата памет се съставя таблицата на адресното съответствие.

Овърлейното менажиране на паметта също има своите недостатъци. Най-същественият от тях се състои в това, че проектирането на овърлейната структура на програмата е дело и ангажимент на програмиста, който в допълнение следва да познава и съответните хардуерни параметри на компютърната система. При готов продукт преносимостта върху друга машина е проблемна.

3. Памет с динамично разпределение - (swapping)

Когато компютърната система се определя като пакетна, описаните по-горе техники са напълно достатъчни. Обаче в системи, в които функционирането е организирано на принципа “с разделяне на времето”, са възможни ситуации когато паметта не е в състояние да съдържа всички потребителски процеси. Тогава се прибягва към свапинг – преместване (изхвърляне) на цели процеси от паметта върху диска и обратно. Изхвърленият процес може да бъде върнат или в същото адресно пространство, откъдето е бил изваден, или в друго. Последното ограничение се диктува от метода за свързване.

Този метод за управление на паметта може значително да увеличи времето за превключване на контекста. Времето за изхвърляне се намалява, ако върху диска се дефинира специална област за свапинг. Обменът с диска се извършва на блокове с голям обем.

4. Памет с променливи дялове

Този метод е по-гъвкав по сравнение с първия. Първоначално цялата памет е свободна и предварително неразделена. На първото постъпило задание се заделя точно толкова памет, колкото му е необходима. След снемането на процеса, паметта временно се освобождава. След известно време паметта представлява променлив брой дялове с различен обем. Междинните свободни участъци могат да бъдат обединявани. Работата на менажера на паметта се състои в анализ на заявките за свободна памет (дял), избор на най-подходящия, зареждане на процеса в избрания дял и последваща актуализация на таблиците на свободните и на заетите области в оперативната памет. Аналогична корекция се извършва при снемане на процесите, когато те завършат изпълнението си. Свързването на адресите (виртуални с физически) може да се извършва по време на зареждането и изпълнението.

При този метод за управление на паметта се получава външна фрагментация, изразяваща се в голям брой неизползвани участъци, които не са присвоени към никой процес. Различните стратегии за зареждане на процесите – най-подходящия или първия най-подходящ или друг, слабо влияят на фрагментацията. Любопитно е да се знае, че стратегията за избор на най-подходящия дял в редица случаи се е оказвала най-неподходяща. Това се обяснява с факта, че тази стратегия води до натрупване на много и разхвърляни незаети блокове. Има сведения, че тези области заемат до 1/3 от цялата оперативна памет.

С външната фрагментация се борят чрез “компресия” (обединяване) на свободните (или на заетите) области в посока на нарастващите (намаляващите) адреси, така щото свободната памет да образува един цялостен участък. Този метод може да срещнете и под наименованието схема с преместваеми дялове.

Определение на понятието виртуална памет

Както беше изяснено в предидущата глава, една програма е активна, когато се намира в оперативната памет. Обемът на тази памет обаче е ограничен, което както вече споменахме, представлява реален проблем при изпълнение на големи по обем програми, работещи с големи по обем масиви от данни. Ето защо освен скоростните особености, върху организацията на запомнящата система, влияние оказва и капацитетът (обемът) на адресното пространство. От друга страна, както е показано на фигура 6.1.1, оперативната памет се разширява (допълва) отдолу чрез външната памет, която по своя физически характер, има практически неограничен обем. Така комбинацията от основна и външна памет може да реши изказания по-горе потребителски проблем, свързан с ограничения обем на оперативната памет. За целта трябва да се реализира механизъм за прехвърляне на актуалните части на програмата и данните от външната памет в основната. Обратно, загубилите активност части следва да освобождават заеманата памет. Ако това са данни, възниква проблемът с актуалността, който вече коментирахме. Очевидно е, че този механизъм съответствува на механизма, обслужващ буферната памет. Задачите, свързани с управлението на паметта – структуриране, разпределение, планиране, водене на текущия отчет, преразпределение, зареждане и въобще събирателното memory management, е същностно свойствена на операционните системи.

Като се има предвид сложността на операциите четене (въвеждане) и запис (извеждане) от/във външната памет и някои други съображения, като например тези, свързани с мултипрограмния режим на работа на процесора, се стига до заключението, че задачата за управление на йерархическата памет от страна на програмиста, е твърде сложна задача. В същото време, разполагането на едно програмно осигуряване по продължението на двете нива на запомнящата система създава впечатлението, че адресното пространство е разширено по посока на външната памет. В тази връзка естествено възниква желанието за една хомогенна (единна) интерпретация на запомнящата система.

Единната интерпретация е възможна само като абстрактна. Понятието “логическо или още виртуално адресно пространство”, обвързва в една обща апаратно-програмна система скъпата и бърза оперативна памет с бавната и евтина външна памет. Абстрактната интерпретация на запомнящата система е възможна само чрез понятието адресно пространство. Практически, физическата запомняща система, която е съставена от различни запомнящи устройства, може да се разбира като хомогенна, само ако на нея се гледа като на едно "неограничено" по обем адресно пространство. Това абстрактно адресно пространство "заличава" отделните нива на физическата памет. Основният принцип, върху който могат и се реализират механизмите за управление на паметта, както вече видяхме от изложения по-горе преглед, е “разделяй и властвай”.

Така окончателно можем да определим, че системата, състояща се от тази интерпретация, от механизмите за реализация на съответствието между абстрактните (логическите) и физическите адреси и механизмите за управление на обмена между основната и външната памети, се нарича виртуална памет. Виртуалната памет е адресируема памет. Адресът се нарича виртуален, но може да бъде срещнат в различни литературни източници и под наименованията логически, математически, абстрактен, хипотетичен. Посочените три съставни части на виртуалната памет позволяват на програмиста, при реализиране на потребителската задача, да разглежда компютърната запомняща система като памет с едно ниво, принадлежаща единствено на неговата програма. Възможността да разполага със своя собствена и неограничена по обем памет означава, че програмистът е освободен от всички грижи свързани с управлението на физическата памет.

Механизмите на виртуалната памет се реализират с апаратни и програмни средства. Основните задачи, които се решават с помощта на тези механизми са:

а) Преобразуване на виртуалните адреси, които се съдържат в машинните команди, и които процесорът издава, във физически ;

б) Управление на динамичното разпределение на информацията между отделните нива на физическата памет по време на хода на изчислителния процес ;

в) Защита на информацията от опити за неправомерен достъп и за неправомерно използуване, което е възможно поради нейното движение по йерархията на паметта.

За да може процесорът (който олицетворява програмиста) да работи в абстрактното адресно пространство на виртуалната памет, трябва да притежава система за поддръжка на значително по-дълги адреси от тези, необходими за работа с основната памет. Така например в процесори на Intel дължината на виртуалния адрес е 48 бита, а в процесори на IBM той е 52 битов. В съвременните процесори този параметър еволюира. Тези данни не ограничават производителите.

Структура на виртуалния адрес

Най-общият вид на структурата на виртуалния адрес е показана на фигура 6.4.1. Тя се състои от 2 основни полета:

· Индекс на линейното адресно пространство на процесора ;

· Линеен адрес на процесора.

Фиг. 6.4.1. Обща структура на виртуален адрес

Индексът, с дължина от V[b], представлява старшата част на виртуалния адрес. Младшата част на виртуалния адрес съдържа линейния адрес на процесора, който е с дължина L[b]. Нека припомним, че обемът на физическото адресно пространство на процесора се определя именно от дължината на този адрес:

При типичната дължина L=32[b], обемът на линейното адресно пространство на процесора е Q=4[G]. В различните реални процесори двете части на виртуалния адрес могат и се структурират по различен начин. Във всички случаи обаче концептуалното разбиране е общо, а то е следното: всяка отделна програма притежава формално цялото адресно пространство на процесора и разполага в него съставните си части както за нея е най-удобно. Адресно пространство на всяка отделна програма има размерите на адресното пространство на процесора, защото машинните команди, с които е реализирана, са определени именно за това адресно пространство. С други думи в адресната част на машинните команди няма място за индекса – в машинните команди се адресират операнди или команди в адресното пространство на процесора. Притежаваното от дадена програма адресно пространство не е фактическо, а както казахме по-горе – то е формално. Можем да кажем, че текстът на програмата е формален в смисъла на употребените в него адреси на клетки. Превключването, което прави операционната система, от една програма към друга програма, означава превключване на съответните им адресни пространства. В този смисъл съдържанието на полето индекс (вижте по-горе фигура 6.4.1) се управлява от операционната система и то не е структурен елемент на машинните команди. В смисъла на всичко казано до момента можем да си представим виртуалната памет като един набор от паралелни адресни пространства, както е илюстрирано на следващата фигура:

Фиг. 6.4.2. Структурна представа за виртуалната памет като множество
от паралелни адресни пространства на процесора

Броят S на паралелните адресни пространства се определя от дължината на индекса:

Номерът (индексът) на актуалното адресно пространство, принадлежащ на дадена програма (машинна команда), се назначава от операционната система и по време на нейното изпълнение по определен начин се използва за селектирането му. При изпълнение на избраната програма, физическото адресно пространство (или отделни негови части) се отъждествя по съдържание с принадлежащото й виртуално адресно пространство под стойността на приписания от ОС индекс.

В подкрепа на казаното ще дадем пример с ранен процесор на Intel, в който реалната дължина на индекса остава 14[b], тъй като 2 бита се отделят за реализация на защита, при което обемът на виртуалното адресно пространство се определя по формулата:

Докато виртуалното пространство има впечатляващия обем от 64 тера, то физическото адресно пространство, видимо за потребителя, е 4[G], тъй като дължината на линейния адрес е 32[b]. Що се отнася до другия пример – процесор на IBM, съответният обем е 4 пета:

И тук обаче физическото адресно пространство е само 4[G], тъй като дължината на линейния адрес в този процесор е също 32[b].

Когато в процесора се изпълняват машинните команди на дадена програма, самите те, както и техните операнди следва да се намират фактически във физическата оперативна памет. И тогава, когато една команда, заредена в процесора, подава адреса на своя операнд и той трябва да се извлече реално от реална клетка, еквивалентността между логическия линеен адрес, който се съдържа в нея и реалния адрес на операнда във физическата памет, се нарушава. Това е така по много причини. На първо място можем да отбележим, че в реалната памет стоят непрекъснато заредени работещи елементи на операционната система, които не могат да бъдат отстранени. На второ място можем да добавим, че във всяка компютърна система част от адресното пространство е твърдо заето от постоянна памет, която съдържа софтуер, осигуряващ жизнеността на системата като цяло. Без да се впускаме в подробно описание на структурирането на адресното пространство от гледна точка на операционната система, нещо което излиза извън рамките на нашите интереси, изказаните току що твърдения са достатъчни за потвърждаване на тезата, че виртуалното адресно пространство не може да бъде “надянато” в пълно съответствие върху физическото, тъй като в последното се съдържат някои постоянни елементи. С други думи, отделните елементи на актуалната потребителска програма не могат да бъдат заредени в оперативната памет в пълно съответствие с виртуалното им разпределение, т.е. с разпределението, което е направил потребителя (или компилатора). Така възниква задачата за преобразуване на виртуалните линейни адреси, съществуващи в текста на програмата в реални, физически адреси. Или с други думи, линейният адрес, който определихме по-горе, не е физически (действителния) адрес на съответните команди и данни. В този смисъл задачата за преобразуване на линейния адрес, който е част от виртуалния, е неизбежна и много актуална. Тази задача следва да се решава в пълна тайна от потребителя, т.е. тя трябва да се решава с апаратни или с апаратно програмни средства, нямащи нищо общо с потребителските програми.

Задачата за преобразуване на виртуалния адрес във физически се възлага на устройството за управление на паметта (MMU – Memory Management Unit), чието място в йерархията на запомнящата система е показано по-долу на фигура 6.4.3.

Фиг. 6.4.3. Място на механизмите на виртуалната памет

Ще се спрем на общата организация на изчислителния процес след така въведените понятия. Нека приемем, че в оперативната памет е заредена и е стартирана дадена програма. Фактът, че програмата (или нейна част) е заредена, означава, че нейният код е записан в оперативната памет. При това зареждане отделните машинни команди и техните операнди са попаднали в клетки, чиито адреси, както вече отбелязахме, не са онези, които е имал предвид програмиста. В това се състои и несъответствието между виртуалните адреси, които ще излизат от машинните команди (от процесора) при тяхното изпълнение. И ако те се подават по адресната шина направо в оперативната памет, програмата няма да успее да изпълни предназначението си. Ясно е, че този вариант е неработоспособен, ето защо ще разглеждаме системата в комплект със средствата за проектиране (mapping) на виртуалния адрес върху физическото адресно пространство.

Проектирането, на този начален етап, можем да разбираме като обикновена подмяна. В най-тривиалния случай, когато програмата не е разделена на части, съответствието се постига чрез константно отместване, както е показано на следващата рисунка:

Фиг. 6.4.4. Съответствие чрез отместване

Както се вижда, заредената във физическото адресно пространство програма продължава да има изходния си текст, но всички нейни команди и данни са отместени спрямо началния адрес (00000) до адрес (aaa). Следователно всеки виртуален адрес V_addr, по който програмата прави обръщение, се преобразува във физически F_addr, според формулата

F_addr = V_addr + [aaa] .

Функционалната зависимост на това преобразуване може да се постигне с апаратни средства.

Представеният случай е твърде елементарен и можем да кажем, че в чист вид не се среща. Обикновено зареждането на потребителските програми е свързано с тяхното разчленяване на по-малки (съставни) част, които могат да имат различни или еднакви размери, с което се цели по-ефективно използване на физическата памет. Структурирането на програмите позволява разнообразни ситуации при тяхното зареждане в оперативната памет. Каквито и да са тези ситуации обаче, заявеният от програмата (командата) (процесора) виртуален адрес следва да бъде проектиран (преобразуван) в правилен физически адрес - фигура 6.4.5.

Фиг. 6.4.5. Съответствие при структурирана програма

Ситуациите, които могат да възникнат, когато се заяви виртуален адрес към оперативната памет, в този случай са много по-комплицирани. Всяко структуриране на програмите на отделни части (блокове) води до съответното структурно интерпретиране и на самия адрес. Ако е заявен виртуалният адрес V_addr, това означава, че той принадлежи примерно на блок №(M) с отместване K вътре в него. В резултат на проектирането върху физическата памет заявеният адрес се намира в блок №(N), със същото отместване K вътре в него. Ако в блок №(N) се съдържат данни, които наистина принадлежат на програмата, това е щастливият случай – достъпът е осигурен и основната операция се изпълнява успешно. Ако обаче съдържанието на виртуалния блок №(N) не е заредено в оперативната памет, проекторът определя неговото местоположение върху външната памет. За да завърши заявената основна операция, следва да се намери свободно място за новия блок №(N), съдържанието му да се прехвърли от диска в оперативната памет в така избраното място, а неговият начален адрес да се зареди като актуален в проектора на тази програма. Тук, в процеса на търсене, е възможно да се установи, че липсва свободно място за поместване на заявения блок. По-нататъшните действия са аналогични на описаните за кеш паметта – търси се кандидат за изхвърляне от оперативната памет, той се изхвърля във външната памет, а на негово място в обратна посока се прехвърля заявеният блок. Едва когато липсващият блок от програмата бъде налице в оперативната памет, основната операция, заявена от програмата, може да бъде изпълнена.

С казаното до момента ще завършим общите обяснения за новото понятие “виртуална памет”. Подробностите, отнасящи се до различните методи за преобразуване на виртуалния адрес във физически и техническите средства за тяхното реализиране, ще изложим в следващите раздели.

Виртуални машини върху виртуална памет и виртуален вход/изход

Съществува още едно предизвикателство за виртуализацията на виртуалната памет, което се дължи на това, че всяка гост ОС на всяка виртуална машина управлява свой собствен набор от таблици на страници. Така качването на различни ОС на един физически компютър не може да бъде така непосредствено. За да бъде това възможно, VMM (Virtual Machine Monitor) въвежда понятия за реална и за физическа памет (които често се третират като синоними) и разглежда физическата памет като отделно, междинно ниво, намиращо се между виртуалната памет и физическата памет. (Някои автори използват термините виртуална памет, физическа памет и памет на машината, за да назоват същите три нива.) Гостуващата ОС структурира виртуалната памет в реална памет чрез свои таблици на страници, а таблиците на страниците на VMM структурират реалната памет за гостите във физическата памет.

Архитектурата на виртуалната памет се задава или чрез таблици на страниците, както е в IBM VM-370 и в микропроцесор Intel 80x86, или чрез TLB структура, практикуваща се в много RISC архитектури, каквито вече представихме. Вместо да използва допълнително ниво като заобиколен път при всеки достъп до паметта, VMM поддържа таблица на сенчеста страница, която директно се преобразува от виртуалното адресно пространство на госта във физическото адресно пространство на хардуера. Чрез откриване на всички модификации на таблицата на страниците на госта, VMM може да гарантира, че записите в таблицата на сенчестите страници, използвани от хардуера за преобразуване, съответстват на тези в средата на гост ОС, с изключение на правилните физически страници, заменени с реалните страници в таблиците на госта. Следователно VMM трябва да открива всеки опит на гост ОС да промени своята таблица на страници или да осъществи достъп до указателя на таблицата на страниците. Това обикновено се прави чрез защита срещу записване на таблиците на страниците за госта и откриване на всеки достъп до указателя на таблицата на страниците от гост ОС. Както беше отбелязано по-горе, последното се случва естествено, ако достъпът до указателя на таблицата на страници е привилегирована операция.

Архитектурата на IBM 370 решава проблема с таблицата на страниците през 70-те години с помощта на допълнително индиректно ниво, което се управлява от VMM. ОС за гости поддържа таблиците на страниците си както преди, така че страниците в сянка стават ненужни. AMD предложи подобна схема своя Pacifica, който е ревизия на i80x86.

За да виртуализира TLB в много RISC компютри, VMM управлява реален TLB и поддържа копие на съдържанието на TLB на всяка гост VM (виртуална машина). За да се постигне това, всички команди, които имат достъп до TLB, трябва да бъдат прихванати. TLB с етикети за идентификация на процеса могат да поддържат комбинация от записи от различни VM и VMM, като по този начин се избягва изчистването на TLB на VM при превключване. Междувременно във фонов режим VMM поддържа структура с виртуалните идентификатори на процесите на VM, както и техните реални идентификатори.

Последната част от архитектурата за виртуализация е входно/изходната система. Това е най-трудната част от виртуализацията на системата, поради нарастващия брой входно/изходни устройства, свързани към компютъра и нарастващото им разнообразие.

Следващото затруднение е свързано със споделянето на реално устройство между множество виртуални машини. Съществена трудност е и поддържането на множество драйвери на устройства, които са необходими, особено ако различни гост ОС се поддържат в една и съща VM система. Илюзията за VM може да се поддържа като се предоставят на всяка VM общи версии за всеки тип за входно/изходен драйвер и след това се оставя VMM да обработва реални входно/изходни данни.

Методът за структуриране от виртуално към физическо входно/изходно устройство зависи от вида на устройството. Например, физическите дискове обикновено се разделят от VMM, за да се създадат виртуални дискове за виртуални машини за гости, а VMM поддържа структура от виртуални пътечки (цилиндри) и сектори за преобразуване към физическите. Мрежовите интерфейси често се споделят между виртуални машини в много кратки времеви срезове и работата на VMM е да следи съобщенията за виртуалните мрежови адреси, за да гарантира, че гостуващите виртуални машини получават само съобщенията, предназначени за тях.

Пример за монитор на виртуална машина (VMM). Виртуална машина Xen

В началото на разработването на виртуални машини станаха очевидни редица неефективности. Например, когато гост ОС управлява виртуалната си структура за преход към реална страница, но тази структура се игнорира от VMM, който извършва действителното структуриране на физически страници. С други думи, получени са значителни загуби, само за да бъде гостната ОС “щастлива". За да намалят неефективността от този вид, разработчиците на VMM решиха, че може да си струва да позволят на гост ОС да е наясно, че се изпълнява на VM. Например, гост ОС може да възприема истинската памет в такъв обем, колкото нейната виртуална памет, така че да не се изисква управление на паметта от гост ОС.

Разрешаването на малки модификации на гост ОС за опростяване на виртуализацията се нарича паравиртуализация, а Xen VMM с отворен код е добър пример. Xen VMM, който се използва в центровете за данни за уеб услуги на Amazon, предлага операционна система за гости с абстракция на виртуална машина, подобна на физическия хардуер, при което отпадат много от обезпокоителните елементи. Например, за да избегне почистването на TLB, Xen се структурира в горните 64 [MiB] на адресното пространство на всяка VM. Тя позволява на гост ОС да разпределя страници, като само проверява дали не нарушава ограниченията за защита. За да защити операционната система за гости от потребителските програми във VM, Xen се възползва от четирите нива на защита, налични в 80x86. Xen VMM работи на най-високото ниво на привилегии (0), гост OS работи на следващото ниво (1), а приложенията се изпълняват на най-ниското ниво на привилегии (3). Повечето операционни системи за 80x86 поддържат всичко в нива на привилегии 0 или 3. За да работи правилно подгрупата, Xen модифицира гост ОС, така че да не използва проблемните части от архитектурата. Например, портът на Linux към Xen променя около 3000 реда или около 1% от специфичния за i80x86 код. Тези промени обаче не засягат приложните двоични интерфейси на гост ОС. За да опрости входа/изхода на виртуални машини, Xen присвоява привилегирована виртуална машини към всяко хардуерно входно/изходно устройство. Тези специални виртуални машини се наричат драйвери на домейни. (Xen нарича своите виртуални машини “домейни“). Драйверните домейни изпълняват физическите драйвери на устройствата, въпреки че прекъсванията все още се обработват от VMM, преди да бъдат изпратени до съответния домейн на драйвера. Редовните виртуални машини, наречени гост домейни, изпълняват прости виртуални драйвери на устройства, които трябва да комуникират с физическите драйвери на устройства в през канал за достъп до физическия входно/изходен хардуер. Данните се изпращат между госта и драйвера домейн чрез пренасочване на страници.

Архитектура за защита на командната система

Защитата е съвместно усилие на хардуерната архитектура и на операционните системи. С еволюцията конструкторите трябваше да модифицират някои неудобни детайли в съществуващите архитектури, свързани с машинните команди, след като виртуалната памет стана популярна. Например, за да поддържат виртуална памет в системата IBM 370, конструкторите трябвало да променят успешната архитектура на командната система на IBM 360, за което беше съобщено само преди няколко години. За да може е една система да се инсталират виртуални машини подобни корекции се правят и днес. Например, командата POPF (Pop from stack into Flags) в процесори i80x86 зарежда регистрите на флаговете в горната част на програмния стек. Един от флаговете е флагът за разрешаване на прекъсванията (IE - Interrupt Enable). До преди последните промени в подкрепа на виртуализацията, изпълнението на инструкцията POPF в потребителски режим променя всички флагове с изключение на IE. В системен режим тази команда променя флага IE. Тъй като една гост ОС работи в потребителски режим върху виртуалната машина, това е проблем, тъй като тя би очаквала да види променен флага IE. Разширенията на архитектурата i80x86 за поддръжка на виртуалните режими премахнаха този проблем.

В исторически план хардуерът на мейнфрейма на IBM и VMM предприеха три стъпки за подобряване на производителността на виртуални машини:

1. Намаляване на разходите за виртуализация на процесора ;

2. Намаляване на режийните разходи за прекъсвания поради виртуализация ;

3. Намаляване на разходите за прекъсвания, чрез управление на прекъсванията до правилната виртуална машина, без извикване на VMM.

IBM все още е златният стандарт на технологията за виртуални машини. Например, мейнфреймът на IBM е управлявал хиляди виртуални машини за Linux през 2000 година, докато Xen е управлявал само 25 през 2004 г.

В последните версии на чипсетите Intel и AMD са добавени специални инструкции за поддръжка на устройства във виртуална машина, за маскиране на прекъсвания на по-ниски нива от всяка виртуална машина и за насочване на прекъсванията към съответната виртуална машина.

Съвместимост на кешираните данни

Данните могат да бъдат намерени в паметта и в кеша. Докато процесорът е единственият компонент, който променя или чете данните, а кешът стои между процесора и паметта, то има малка опасност процесорът да види старото им копие. Както по-късно ще поясним, множеството процесори и В/И устройства създават възможност копията на данните да са несъвместими, което ще доведе до използване (четене) на грешно копие. Честотата на проблема с кохерентността е различна за кеш паметта и за входно/изходната система. Множеството копия на данни са рядко може да бъде избягнато. Всяка програма, работеща на множество процесори, ще иска да има копия на едни и същи данни в няколко кеша. Изпълнението на многопроцесорна програма зависи от производителността на системата при споделяне на данни.

Въпросът за кохерентността на кеша на входно/изходната система е следният: Къде стои входно/изходната система компютъра? Между В/И устройство и кеша или между В/И устройство и основната памет? Ако входът доставя данни в кеша, а изходът чете данни от кеша, В/И устройство и процесорът виждат едни и същи данни. Трудността при този подход е, че той пречи на процесора и може да доведе до спиране на В/И процес. Въведеното може също да повлияе на кеша, като замести част от информацията с нови данни, които е малко вероятно да бъдат достъпни скоро.

Целта на входно/изходната система в компютър с кеш памет е да се предотврати проблемът със застоялите данни, като се намесва възможно най-малко. Следователно много системи предпочитат входно/изходните процеси да се случват директно с основната памет, като основната памет действа като В/И буфер. Ако се използва кеш за запис, тогава паметта ще има актуално копие на информацията и няма да има остарели данни за извеждане. Това предимство е причината, поради която процесорите са използвали стратегията write through. Уви, записването обикновено се изпълнява днес само в кешовете с данни L1, подкрепени от кешовете L2, които използват стратегия обратен запис (write back).

Въвеждането на данни изисква допълнителна работа. Софтуерното решение трябва да гарантира, че в кеша няма блокове от входния буфер. Страница, съдържаща буфера, може да бъде маркирана като некешируема и операционната система винаги може да въведе такава страница. Алтернативно, операционната система може да изчисти адресите на буфера от кеша, преди да се изпълни въвеждането. Възможното хардуерно решение е да се провери дали подаваните В/И адреси са в кеша. Ако в кеша има съвпадение на В/И адреси, записите в кеша се блокират, за да се избегнат остарели данни. Всички тези подходи могат да се използват и за извеждане в кешове с обратно изписване (write back).

Кохерентността на кеш паметта на процесора е критична тема в ерата на многоядрените процесори и беше разгледана подробно в предходен раздел.

Следващият раздел е:

6.4.1. Методи за преобразуване на виртуалните адреси