http___en.wikipedia.org_wiki_Talk_Popek_and_Goldberg_virtualization_requirements.xml
1.1 2.1 2.2 2.3 2.4 2.5 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 11.1 12.1 12.2 12.3 13.1 14.1 15.1 16.1 17.1 18.1 19.1 19.2 20.1 20.2 20.3 20.4 20.5 21.1 22.1 23.1 24.1 25.1 26.1 27.1 28.1 29.1 30.1 30.2 31.1 31.2 31.3 31.4 32.1 33.1 33.2 34.1 34.2 35.1 36.1 37.1 37.2 37.3 37.4 37.5 37.6 38.1 39.1 39.2 40.1 40.2 40.3 40.4 41.1 42.1 43.1 44.1 44.2 45.1 46.1 47.1 48.1 49.1 50.1 51.1 52.1 53.1 54.1 54.2 55.1 56.1 56.2 57.1 59.1 60.1 61.1 62.1 64.1 65.1 66.1 67.1 68.1 69.1 70.1 71.1 72.1 73.1 74.1 74.2 75.1 76.1 76.2 76.3 76.4 76.5 76.6 76.7 77.1 77.2 77.3 78.1 79.1 81.1 81.2 82.1 83.1 84.1 85.1 86.1 87.1 87.2 87.3 87.4 87.5 88.1 89.1 89.2 90.1 90.2 91.1 91.2 91.3 91.4 92.1 92.2 92.3 92.4 93.1 93.2 93.3 93.4 94.1 94.2 94.3 95.1 95.2 95.3 96.1 97.1 98.1 99.1 100.1 100.2 100.3 101.1 101.2 101.3 102.1 102.2 102.3
Изисквания за виртуализация на Попек и Голдбърг Изискванията за виртуализация на Попек и Голдбърг са набор от условия, достатъчни за компютърна архитектура, която да поддържа ефективно системна виртуализация. Те са въведени от Gerald J. Popek и Robert P. Goldberg в тяхна статия от 1974 Формални изисквания за виртуализация на трето поколение архитектури.[1] . Въпреки, че тези изисквания са получени чрез опростени предположения, те все още представляват удобен начин за определяне дали дадена компютърна архитектура поддържа ефективна виртуализация и да предоставят насоки за проектиране на виртуализирани компютърни архитектури. Съдържание - 1 Дефиниция на монитор на виртуална машина - хипервайзор (VMM, hypervisor) - 2 Теореми за виртуализация - 3 Обработка на критичните инструкции - 4 Набор от инструкции за общи архитектури - 5 Производителността на практика - 6 Вижте също - 7 Източници Дефиниция на монитор на виртуална машина - хипервайзор (VMM, hypervisor)[редактиране | edit source] Системните виртуални машини могат да виртуализират пълен набор от хардуерни ресурси, включително процесор (или процесори), ресурси за памет и съхранение и периферни устройста. Мониторът (VMM, наречен също hypervisor) е част от софтуера, който осигурява абстракция на виртуална машина. Съществуват три важни свойства на среда, създадена от VMM: [2] - Еквивалентност/Вярност - Програма, работеща под контрола на VMM, трябва да показва поведение идентично по същество с това, демонстрирано, когато работи директно на еквивалентна машина. - Контрол на ресурсите/Безопасност - VMM трябва да има пълен контрол върху виртуализираните ресурси. - Ефективност / Изпълнение - Статистически доминиращата част от машинните инструкции трябва да бъдат изпълнени без намесата на VMM. В терминологията на Popek и Goldberg, една VMM трябва да има и трите свойства. В терминологията, използвана в справочника на Smith и Nair (2005), VMM обикновено се приемат, като отговарящи на свойствата за еквивалентност и контрол на ресурсите, а тези, които допълнително отговарят и на свойството за изпълнение се наричат ефективни VMMs.[3] Popek и Goldberg описват характеристиките, които набора от инструкции (Instruction Set Architecture - ISA) на физическата машина трябва да притежава, за да задвижи VMM, със горните три свойства. Техният анализ извлича такива характеристики с помощта на модел на архитектури от трето поколение (например, IBM 360, Honeywell 6000, DEC PDP-10), който е все пак достатъчно общ, за да бъде разширен до съвременни машини. Този модел включва процесор, който работи или в системен или потребителски режим, и има достъп до линейна, постоянно адресируема памет. Предполага се, че подгрупа на набора от инструкции е достъпна само, когато е в системен режим и че паметта се адресира относително в зависимост от регистър на преместванията. I/O и прекъсванията не са моделирани. Теореми за виртуализация[редактиране | edit source] За да извлекат своите виртуализационни теореми, които дават достатъчни (а не необходими) условия за виртуализация, Popek и Goldberg въвеждат класификация на инструкциите на ISA в три различни групи: - Привилегировани инструкции - тези, които прекъсват (trap), ако процесорът е в потребителски режим (user mode) и не прекъсват, ако е в системен режим (supervisor mode). - Инструкции, чувствителни към контрола - Тези, които се опитват да променят конфигурацията на ресурсите в системата. - Инструкции, чувствителни към поведението - Тези, чието поведение или резултат зависи от конфигурацията на ресурсите (съдържанието на регистър за преместването или режима на процесора). Основният резултат от анализа на Popek и Goldberg може да бъде изразен, както следва: Теорема 1. За всеки конвенционален компютър от трето поколение (third-generation computer), ефективен VMM може да се конструира, ако наборът от чувствителни инструкции за този компютър е подгрупа на набора от привилегировани инструкции. Интуитивно, теоремата гласи, че, за да се изгради VMM, е достатъчно всички инструкции, които могат да засегнат правилното функциониране на VMM (чувствителни инструкции), винаги прекъсват и предават контрола към VMM. Това гарантира свойството за ресурсен контрол. Непривилегированите инструкции трябва вместо това да се изпълнят нативно (т.е. ефективно). Запазването на свойството за еквивалентност също следва от това. Тази теорема също осигурява проста техника за създаване на VMM, наречена trap-and-emulate виртуализация, от скоро наричана класическа виртуализация: защото всички чувствителни инструкции работят добре, всичко, което VMM трябва да направи, е да прихваща и емулира всяка една от тях.[4] Свързан с това проблем е, че се извличат достатъчни условия за рекурсивна виртуализация, което означава, че може да се създадат условия, под които може да се стартира VMM, така че да работи върху копие на себе си. Popek и Goldberg представят следните (достатъчни) условия: Теорема 2. Обикновен компютър от трето поколение (third-generation computer) може да се виртуализира рекурсивно, ако - е възможен за виртуализация и - може да се създаде VMM за него без никакви времеви зависимости. Някои архитектури като тези без хардуерна помощ x86 не отговарят на тези условия, така че те не могат да бъдат виртуализирани по класическия начин. Но архитектурите все още може да бъдат напълно виртуализирани (в x86 случая - CPU и MMU нивата) чрез използване на различни техники като двоичен превод, който заменя чувствителните инструкции, които не генерират прекъсвания [4] , които понякога се наричат решаващи инструкции. Това допълнително обработване, обаче, прави VMM по-малко ефективна на теория. [5], но също така и хардуернитe капани имат значителни разходи по изпълнението.. Една добре настроена кешираща система за двоичен превод може да достигне сравнима производителност и го прави в случая на x86 двоичен превод спрямо първото поколение на x86 хардуерна помощ, което просто направи чувствителните инструкции (лесни за прихващане)trappable. [6] Ефективно, това дава една теорема с различни условия по достатъчността . Обработка на критичните инструкции[редактиране | edit source] Условията за виртуализация, изразени в теорема 1, могат да бъдат намалени за сметка на ефективността. Изградени са VMM за невиртуализиращ набор от инструкции (ISA) (в смисъла на Popek и Goldberg). Виртуализацията на такива архитектури изисква правилна обработка на „критичните инструкции”, т.е. чувствителни, но непривилегировани инструкции. Един подход, известен като "пачване" (patching), усвоява техники, обикновено използвани в динамичното прекомпилиране (dynamic recompilation) : критичните инструкции са открити по време на изпълнение и се прекъсват във VMM. Предложени са различни механизми като кеширане на кода за емулация или виртуализация с помощта на хардуер (hardware assists), за да направят процеса на „пачване” по-ефективен. Един различен подход е този на паравиртуализацията (paravirtualization), който изисква да се модифицират („пренесат”) гост-операционните системи преди да заработят във виртуалната среда. Набор от инструкции за общи архитектури[редактиране | edit source] Разделът представя няколко съответни архитектури и как те се отнасят към изискванията за виртуализация. PDP-10[редактиране | edit source] 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[редактиране | edit source] Всички чувствителни инструкции в System/370 са привилегировани: отговарят на изискванията за виртуализация.[8] Motorola MC68000[редактиране | edit source] Motorola MC68000 има само една непривилегирована чувствителна инструкция: - MOVE from SR Тази инструкция е чувствителна, защото дава достъп до целия статус регистър, който включва не само условен код (condition codes), но и потребител/супервайзор бит, ниво на прекъсване и контрол на средата. В по-късните членове на фамилията, като започнем от MC68010, инструкцията MOVE from SR е направена привилегирована и съществува нова инструкция MOVE from CCR, която дава достъп единствено до регистъра на условния код. IA-32 (x86)[редактиране | edit source] Наборът от IA-32 инструкции на процесора Pentium съдържа 17 чувствителни, непривилегировани инструкции. Те могат да се разделят в две групи: Чувствителни регистрови инструкции: четене или изменяне на чувствителни регистри и/или места на памет като часови регистър или регистър на прекъсванията: - 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 процесорите да отговорят на изискванията за виртуализация на Popek и Goldberg IA-64[редактиране | edit source] Усилията, необходими за поддръжка на виртуализацията върху архитектурата IA-64, са описани в статия от 2000г. от Magenheimer и Christian. SPARC[редактиране | edit source] „Хиперпривилегирован” режим за архитектурата UltraSPARC е посочен в „UltraSPARC Architecture 2005” [13]. Дефинира се платформата sun4v [14] , която е надмножество на платформата sun4u, но е съвместима със спецификацията SPARC v9 Level-1[15]. Производителността на практика[редактиране | edit source] Изискването за eфективност в дефиницията на Popek и Goldberg за VMM се отнася единствено до изпълнението на непривилегировани инструкции, които трябва да се изпълнят нативно. Това отличава един VMM от по-общ клас софтуер за емулация на хардуера (emulation). За съжаление, дори и в архитектура, която отговаря на изискванията на Popek и Goldberg, производителността на виртуалната машина може да се различава съществено от реалния хардуер. Ранните експерименти, извършени на System/370 (която отговаря на формалните изисквания на Теорема 1), показват, че производителността на виртуалната машина може да падне до 21% от производителността на нативната машина по някои показатели. Цената за прекъсване и емулиране на привилегированите инструкции във VMM може да бъде значителна. Това накара инженерите на IBM да въведат редица помощен хардуер (hardware assists), което почти удвои производителността на виртуалните машини System/370 [16] Помощният хардуер се е добавял на няколко етапа. Накрая е имало над 100 помощни устройства на последните модели System/370. Един от основните движещи фактори за развитие на помощния хардуер за System/370 беше самата виртуална памет. Когато гостът беше операционна система, която сама по себе си имплементира виртуална памет, дори непривилегированите инструкции можеха да имат по-дълго време за изпълнение – санкция, наложена от изискването за достъп до таблици за преобразуване, което не се използва при нативното изпълнение. (виж shadow page tables).[18] Вижте също[редактиране | edit source] Източници[редактиране | edit source] This citation will be automatically completed in the next few minutes. You can jump the queue or expand by hand - ↑ Rogier Dittner, David Rule, The best damn server virtualization book period, Syngress, 2007, ISBN 1-59749-217-5, p. 19 - ↑ Smith and Nair, p. 387 - ↑ а б Adams and Agesen, 2006, pp. 2-3 - ↑ Smith and Nair, p. 391 - ↑ Adams and Agesen, p. 1 and 5 - ↑ S. Galley. PDP-10 Virtual machines. // Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. 1969, 30–34 с. с. 30–34. - ↑ Smith and Nair, p. 395 - ↑ M68000 8-/16-32-Bit Microprocessor User's Manual, Ninth Edition. Phoenix, AZ, USA, Motorola, Inc., 1993. - ↑ Motorola M68000 Family Programmer's Reference Manual. Phoenix, AZ, USA, Motorola, Inc., 1992. - ↑ 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. - ↑ Daniel J. Magenheimer and Thomas W. Christian. vBlades: Optimized Paravirtualization for the Itanium Processor Family. // Proc. 3rd Virtual Machine Research & Technology Symposium. - ↑ Weaver, David. UltraSPARC Architecture 2005: One Architecture.... Multiple Innovative Implementations (DraftD0.9). Santa Clara, CA, USA, Sun Microsystems, Inc., 2007-05-17. - ↑ Sun Microsystems, Inc.. UltraSPARC Virtual Machine Specification. Santa Clara, CA, USA, 2006-01-24. - ↑ Weaver, David L. и др. The SPARC Architecture Manual: Version 9. San Jose, CA, USA, SPARC International, Inc., 1994. - ↑ Smith and Nair, p. 415-416 and 426 - ↑ Gum, p. 535 - ↑ Gum, p. 533 - Забележки - Smith, Jim и др. Virtual Machines. Morgan Kaufmann, 2005. - Adams, Keith и др. A Comparison of Software and Hardware Techniques for x86 Virtualization. // Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, 2006. 2006-21-2006. Gum, System/370 Extended Architecture: Facilities for Virtual Machines, IBM J. Res. Develop., Vol. 27, No. 6, Nov. 1983, pp. 530–544
1.1 2.1 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 11.1 12.1 12.2 12.3 13.1 14.1 15.1 16.1 17.1 17.2 17.3 18.1 18.2 18.3 18.4 19.1 20.1 20.2 20.3 20.4 21.1 21.2 21.3 21.4 21.5 21.6 22.1 23.1 23.2 23.3 23.4 23.5 23.6 23.7
Talk:Popek and Goldberg virtualization requirements Summary[edit] It would be nice to have a summary of the requirements, examples of processors that do and do not meet the requirements, and explanations of why some do not. Architectures that do not meet the Popek and Goldberg virtualization requirements: - IBM System/360 - Motorola MC68000 - Intel x86 Architectures that do meet the Popek and Goldberg virtualization requirements: - IBM System/370 - Motorola MC68010 Example of an architectural change to support virtualization: - On the Motorola MC68000, the instruction move from status register was not a privileged instruction, but inspected a portion of the privileged machine state. Thus it was not possible for a hypervisor to efficiently trap that instruction when executed by a guest operating system in order to provide the virtual machine status register in place of the host machine status register. The MC68010 fixed this by making move from status register a privileged instruction, and adding a new unprivileged instruction move from condition code register which could be used to read only the portion of the status register not containing privileged state. I agree, I clicked on the link to this page to get the list of requirements but was met with a fluffed up version of what was stated on the linking page. "The Popek and Goldberg virtualization requirements are a set of necessary and sufficient conditions for a computer architecture to efficiently support self-virtualization..." This statement is logically contradictory to the following one: "It is possible for a computer that does not satisfy the Popek and Goldberg virtualization requirements to support a virtual machine, but generally this requires a much more complex virtual machine monitor program and imposes a higher performance penalty." As stated on the link to Necessary and sufficient conditions if the first statement is true, then the only way for a computer architecture to efficiently support self-virtualization is to meet the Popek and Goldberg virtualization requirements. It is then stated that there is another way for a computer to support self-virtualization without satisifying P&G. Can't have it both ways. - I think this article is pretty unclear, but I disagree that there's a logical contradiction. The first quote says "efficiently support", while the second says virtualization is possible but with a higher performance penalty. Of course, any computer can simulate any other computer inefficiently (assuming unlimited resources). Brighterorange 17:59, 16 November 2005 (UTC) 17 or 18 IA32 instructions?[edit] Has anybody counted the IA32 instructions? If I'm right, it's 18. Why does everybody speak about 17 instructions (even Robin&Irvine)?! Is SMSW considered outdated? I agree, this is confusing; however, Robin & Irvine don't exactly say that their list has 17 entries. The enumeration of problematic instructions takes place in Section 3, & there are definitely 18 items listed there. Later (Section 4, para. -3, sentence 2), they say "First, all seventeen unprivileged, sensitive instructions of the Intel architecture could be changed to privileged instructions."; not "First, all the seventeen unprivileged, sensitive instructions of the Intel architecture could be changed to privileged instructions.". It may be that they aren't counting SMSW or some other instruction. Has anyone thought of contacting them for clarification? Does z/Architecture meet the requirements?[edit] The article states that System/370 meets the requirements, but it seems to me that the part of z/Architecture described in Principles of Operation (the main publicly available reference on zArchitecture) does not meet them. There is instruction Extract PSW, which will tell unprivileged user the setting of privileged bit (similar to that Motorola instruction described in the article). If the privileged part of the operating system to be virtualized must run unpriviliged on virtualized machine, and it can find the state if they are privileged or not, it can behave differently in virtualized and non-virtualized environment (by the way, I think this should be made clear in the article). So it seems to me that it's impossible to virtualize zArchitecture by means of privileged instructions. However, on zArchitecture, there is undocumented instruction SIE (Start Interpretive Execution), which dates back to System/370, that is used by LPAR and zVM hypervisors, thus allowing virtualization. But I think that the published instruction set of zArchitecture alone doesn't meet the requirements. Samohyl Jan (talk) 18:41, 31 January 2008 (UTC)