Направо към съдържанието

Изисквания за виртуализация на Попек и Голдбърг

от Уикипедия, свободната енциклопедия

Изискванията за виртуализация на Попек и Голдбърг са набор от условия, които са достатъчни една компютърна архитектура да поддържа ефективно системна виртуализация. Те са въведени от Джералд Попек и Робърт Голдбърг в тяхна статия от 1974 г., „Формални изисквания за виртуализация на трето поколение архитектури“.[1] Въпреки че тези изисквания са получени чрез опростени предположения, те все още представляват удобен начин за определяне дали дадена компютърна архитектура поддържа ефективна виртуализация и да предоставят насоки за проектиране на виртуализирани компютърни архитектури.

Дефиниция на монитор на виртуална машина – хипервайзор (VMM, hypervisor)

[редактиране | редактиране на кода]

Системните виртуални машини могат да виртуализират пълен набор от хардуерни ресурси, включително процесор (или процесори), ресурси за памет и съхранение и периферни устройства. Мониторът (VMM, наречен също hypervisor) е част от софтуера, който осигурява абстракция на виртуална машина. Съществуват три важни свойства на средата, създадена от VMM: [2]

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

В терминологията на Попек и Голдбърг, една VMM трябва да има и трите свойства. В терминологията, използвана в справочника на Smith и Nair (2005), VMM обикновено се приемат че отговарят на свойствата за еквивалентност и контрол на ресурсите, а тези, които освен това отговарят и на свойството за изпълнение, се наричат​​ ефективни VMMs.[3]

Попек и Голдбърг описват характеристиките, които трябва да притежава наборът от инструкции (Instruction Set Architecture – ISA) на физическата машина, за да задвижи VMM с горните три свойства. Техният анализ извлича такива характеристики с помощта на модел на архитектури от трето поколение (например, IBM 360, Honeywell 6000, DEC PDP-10), който е все пак достатъчно общ, за да бъде разширен до съвременните машини. Този модел включва процесор, който работи или в системен, или потребителски режим, и има достъп до линейна, постоянно адресируема памет. Предполага се, че подгрупа на набора от инструкции е достъпна само, когато е в системен режим и че паметта се адресира относително в зависимост от регистър на преместванията. I/O и прекъсванията не са моделирани.

Теореми за виртуализация

[редактиране | редактиране на кода]

За да извлекат своите виртуализационни теореми, които дават достатъчни (а не необходими) условия за виртуализация, Попек и Голдбърг въвеждат класификация на инструкциите на ISA в три различни групи:

Привилегировани инструкции
тези, които прекъсват (trap), ако процесорът е в потребителски режим (user mode) и не прекъсват, ако е в системен режим (supervisor mode).
Инструкции, чувствителни към контрола
Тези, които се опитват да променят конфигурацията на ресурсите в системата.
Инструкции, чувствителни към поведението
Тези, чието поведение или резултат зависи от конфигурацията на ресурсите (съдържанието на регистър за преместването или режима на процесора).

Основният резултат от анализа на Попек и Голдбърг може да бъде изразен, както следва:

Теорема 1. За всеки конвенционален компютър от трето поколение (third-generation computer), ефективен VMM може да се конструира, ако наборът от чувствителни инструкции за този компютър е подгрупа на набора от привилегировани инструкции.

Интуитивно, теоремата гласи, че, за да се изгради VMM, е достатъчно всички инструкции, които могат да засегнат правилното функциониране на VMM (чувствителни инструкции), винаги прекъсват и предават контрола към VMM. Това гарантира свойството за ресурсен контрол. Непривилегированите инструкции трябва вместо това да се изпълнят нативно (т.е. ефективно). Запазването на свойството за еквивалентност също следва от това.

Тази теорема също осигурява проста техника за създаване на VMM, наречена trap-and-emulate виртуализация, от скоро наричана класическа виртуализация: защото всички чувствителни инструкции работят добре, всичко, което VMM трябва да направи, е да прихваща и емулира всяка една от тях.[4]

Свързан с това проблем е, че се извличат достатъчни условия за рекурсивна виртуализация, което означава, че може да се създадат условия, под които може да се стартира VMM, така че да работи върху копие на себе си. Попек и Голдбърг представят следните (достатъчни) условия:

Теорема 2. Обикновен компютър от трето поколение (third-generation computer) може да се виртуализира рекурсивно, ако

  1. е възможен за виртуализация и
  2. може да се създаде VMM за него без никакви времеви зависимости.

Някои архитектури като тези без хардуерна помощ x86 не отговарят на тези условия, така че те не могат да бъдат виртуализирани по класическия начин. Но архитектурите все още може да бъдат напълно виртуализирани (в x86 случая – CPU и MMU нивата) чрез използване на различни техники като двоичен превод, който заменя чувствителните инструкции, които не генерират прекъсвания [4], които понякога се наричат решаващи инструкции. Това допълнително обработване, обаче, прави VMM по-малко ефективна на теория. [5], но също така и хардуерните капани имат значителни разходи по изпълнението.. Една добре настроена кешираща система за двоичен превод може да достигне сравнима производителност и го прави в случая на x86 двоичен превод спрямо първото поколение на x86 хардуерна помощ, което просто направи чувствителните инструкции (лесни за прихващане)trappable. [6] Ефективно, това дава една теорема с различни условия по достатъчността .

Обработка на критичните инструкции

[редактиране | редактиране на кода]

Условията за виртуализация, изразени в теорема 1, могат да бъдат намалени за сметка на ефективността. Изградени са VMM за невиртуализиращ набор от инструкции (ISA) (в смисъла на Попек и Голдбърг).

Виртуализацията на такива архитектури изисква правилна обработка на „критичните инструкции“, т.е. чувствителни, но непривилегировани инструкции. Един подход, известен като „пачване“ (patching), усвоява техники, обикновено използвани в динамичното прекомпилиране (dynamic recompilation): критичните инструкции са открити по време на изпълнение и се прекъсват във VMM. Предложени са различни механизми като кеширане на кода за емулация или виртуализация с помощта на хардуер (hardware assists), за да направят процеса на „пачване“ по-ефективен. Един различен подход е този на паравиртуализацията (paravirtualization), който изисква да се модифицират („пренесат“) гост-операционните системи преди да заработят във виртуалната среда.

Набор от инструкции за общи архитектури

[редактиране | редактиране на кода]

Разделът представя няколко съответни архитектури и как те се отнасят към изискванията за виртуализация.

PDP-10

[редактиране | редактиране на кода]

PDP-10 архитектурата има няколко инструкции, които са чувствителни (променят или заявяват режима на процесора), но не и привилегировани.[7] Тези инструкции съхраняват или възстановяват кода, съдържащ USER или IOT битове.

  • JSR: jump to subroutine
  • JSP: jump and save program counter
  • PUSHJ: push down and jump
  • JRST: jump and restore

System/370

[редактиране | редактиране на кода]

Всички чувствителни инструкции в System/370 са привилегировани: отговарят на изискванията за виртуализация.[8]

Motorola MC68000

[редактиране | редактиране на кода]

Motorola MC68000 има само една непривилегирована чувствителна инструкция:

  • MOVE from SR

Тази инструкция е чувствителна, защото дава достъп до целия статус регистър, който включва не само условен код (condition codes), но и потребител/супервайзор бит, ниво на прекъсване и контрол на средата. В по-късните членове на фамилията, като започнем от MC68010, инструкцията MOVE from SR е направена привилегирована и съществува нова инструкция MOVE from CCR, която дава достъп единствено до регистъра на условния код. [9] [10]

IA-32 (x86)

[редактиране | редактиране на кода]
 Основна статия: X86 virtualization

Наборът от IA-32 инструкции на процесора Intel Pentium съдържа 17 чувствителни, непривилегировани инструкции[11]. Те могат да се разделят в две групи:

Чувствителни регистрови инструкции: четене или изменяне на чувствителни регистри и/или места на памет като часови регистър или регистър на прекъсванията:

    • SGDT, SIDT, SLDT
    • SMSW
    • PUSHF, POPF

Инструкции за системата за защита: отнасят се към система за защита на съхранението и системата за преместване на памет или адрес:

    • LAR, LSL, VERR, VERW
    • POP
    • PUSH
    • CALL, JMP, INT n, RET
    • STR
    • MOV

Въвеждането на наборите от инструкции AMD-V и Intel VT-x през 2005 г. позволява на х86 процесорите да отговорят на изискванията за виртуализация на Попек и Голдбърг.

IA-64

[редактиране | редактиране на кода]

Усилията, необходими за поддръжка на виртуализацията върху архитектурата IA-64, са описани в статия от 2000 г. от Magenheimer и Christian. [12]

SPARC

[редактиране | редактиране на кода]

„Хиперпривилегирован“ режим за архитектурата UltraSPARC е посочен в UltraSPARC Architecture 2005[13]. Дефинира се платформата sun4v [14], която е надмножество на платформата sun4u, но е съвместима със спецификацията SPARC v9 Level-1[15].

Производителността на практика

[редактиране | редактиране на кода]

Изискването за ефективност в дефиницията на Попек и Голдбърг за VMM се отнася единствено до изпълнението на непривилегировани инструкции, които трябва да се изпълнят нативно. Това отличава един VMM от по-общ клас софтуер за емулация на хардуер. Дори и в архитектура, която отговаря на изискванията на Попек и Голдбърг, производителността на виртуалната машина може да се различава съществено от реалния хардуер. Ранните експерименти, извършени на System/370 (която отговаря на формалните изисквания на Теорема 1), показват, че производителността на виртуалната машина може да падне до 21% от производителността на нативната машина по някои показатели. Цената за прекъсване и емулиране на привилегированите инструкции във VMM може да бъде значителна. Това накара инженерите на IBM да въведат редица помощен хардуер (hardware assists), което почти удвои производителността на виртуалните машини System/370 [16] Помощният хардуер се е добавял на няколко етапа. Накрая е имало над 100 помощни устройства на последните модели System/370. [17]

Един от основните движещи фактори за развитие на помощния хардуер за System/370 беше самата виртуална памет. Когато гостът беше операционна система, която сама по себе си имплементира виртуална памет, дори непривилегированите инструкции можеха да имат по-дълго време за изпълнение – санкция, наложена от изискването за достъп до таблици за преобразуване, което не се използва при нативното изпълнение. (виж shadow page tables).[18]

Източници

[редактиране | редактиране на кода]
  1. ↑ Popek, Gerald J. et al. Formal requirements for virtualizable third generation architectures // Communications of the ACM 17 (7). ACM Digital Library, July 1974. (на английски)
  2. ↑ Rogier Dittner, David Rule, The best damn server virtualization book period, Syngress, 2007, ISBN 1-59749-217-5, p. 19
  3. ↑ Smith and Nair, p. 387
  4. ↑ а б Adams and Agesen, 2006, pp. 2 – 3
  5. ↑ Smith and Nair, p. 391
  6. ↑ Adams and Agesen, p. 1 and 5
  7. ↑ S. W. Galley. PDP-10 Virtual machines // Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. 1969, 30 – 34 с.
  8. ↑ Smith and Nair, p. 395
  9. ↑ M68000 8-/16-32-Bit Microprocessor User's Manual, Ninth Edition. Phoenix, AZ, USA, Motorola, Inc., 1993.
  10. ↑ Motorola M68000 Family Programmer's Reference Manual. Phoenix, AZ, USA, Motorola, Inc., 1992.
  11. ↑ John Scott Robin and Cynthia E. Irvine. Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor // Proc. 9th USENIX Security Symposium. 2000.
  12. ↑ Daniel J. Magenheimer and Thomas W. Christian. vBlades: Optimized Paravirtualization for the Itanium Processor Family // Proc. 3rd Virtual Machine Research & Technology Symposium. USENIX, 2000, 73 – 82 с.
  13. ↑ Weaver, David. UltraSPARC Architecture 2005: One Architecture.... Multiple Innovative Implementations (DraftD0.9). Santa Clara, CA, USA, Sun Microsystems, Inc., 17 май 2007. Архив на оригинала от 2009-02-19 в Wayback Machine.
  14. ↑ Sun Microsystems, Inc. UltraSPARC Virtual Machine Specification. Santa Clara, CA, USA, 24 януари 2006. Архив на оригинала от 2007-09-27 в Wayback Machine.
  15. ↑ Weaver, David L. и др. The SPARC Architecture Manual: Version 9. San Jose, CA, USA, SPARC International, Inc., 1994. ISBN 0-13-825001-4. Архив на оригинала от 2004-11-07 в Wayback Machine.
  16. ↑ Smith and Nair, p. 415 – 416 and 426
  17. ↑ Gum, p. 535
  18. ↑ Gum, p. 533
Забележки
  Тази страница частично или изцяло представлява превод на страницата Popek_and_Goldberg_virtualization_requirements в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Взето от „https://bg.wikipedia.org/w/index.php?title=Изисквания_за_виртуализация_на_Попек_и_Голдбърг&oldid=12336750“.